Development of a Process for Continuous Creation of Lean
Value in Product Development Organizations
by
Jin Kato
B. Eng., Aeronautics and Astronautics (1996)
M. Eng., Aeronautics and Astronautics (1998)
University of Tokyo
Submitted to the Department of Mechanical Engineering
in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Mechanical Engineering
MASSACHUSES INSTiTUTE
OF TECHNOLOGY
at the
JUN 162005
Massachusetts Institute of Technology
LIBRARIES
June 2005
©2005 Massachusetts Institute of Technology. All rights reserved.
Signature of Author........
.............................................
Department of Mechanical Engineering
May 6, 2005
.......................
C ertified by ........
............................
Warren Seering
Weber-Shaughness Professor of Mechanical Engineering and Engineering Systems
Thesis Supervisor
A ccepted by ....................................
...............................
Lallit Anand
Chairman, Department Committee on Graduate Students
BARKER
Development of a Process for Continuous Creation of Lean
Value in Product Development Organizations
by
Jin Kato
jkato@alum.mit.edu
Submitted to the Department of Mechanical Engineering
on June 6, 2005 in Partial Fulfillment of the Requirements for
the Degree of Master of Science in Mechanical Engineering
ABSTRACT
Ideas and methodologies of lean product development were developed into tools and processes that help
product development organizations improve their performances. The definition of waste in product
development processes was re-examined and developed into a frugal set to cover all types of waste in product
development processes through preliminary case studies. Value stream mapping (VSM) was optimized for
measuring the waste indicators in product development processes. Typical causes for low product
development project performances were organized into a root-cause analysis diagram.
Three case studies in product development companies were performed. The tools were tested and improved
through intensive interviews with both project managers and engineers. VSM was effective for identifying
and measuring waste indicators. The root-cause analysis diagram was effective for quickly identifying root
causes for low product development project performances. Synchronized uses of these tools made it possible
to measure each root cause's impact on project performances. The result of measurements revealed both
problems shared by all the projects and the ones specific to the projects, indicating that the tools and processes
developed in this research can provide suggestions for continuous improvement of product development
processes.
Some waste indicators were more prevalent than the others, implying that the number of waste indicators to
be considered can be reduced. Inventory of information was prevalent in all the projects, and the analyses of it
implied that Today's product development processes are as premature as those of manufacturing several
decades ago. Wastefulness of information inventory was proved quantitatively. Time spent on one occurrence
of rework was proved to take longer near the end of a project than at the beginning of it.
Thesis Supervisor: Warren Seering
Title: Weber-Shaughness Professor of Mechanical Engineering and Engineering Systems
3
ACKNOWLEDGEMENTS
I would like to express my sincere appreciation to my thesis advisor, Professor Warren
Seering. He has always provided for me invaluable guidance in a manner I have never
experienced. I have learned from him not only knowledge in product development, but also
ways to keep people motivated all the time.
I am also thankful to Professor Seering's students. Victor Tang kindly helped me to find
research investigation opportunities, based on his outstanding carrier in managing big
projects. Christoph Bauch, Martin Graebsch, Josef Oehmen, and Ryan Whitaker made it
possible to formulate my ideas through thoughtful suggestions.
I would like to thank East Japan Railway Company, my employer, for giving me a special
opportunity to learn in the best environment.
I am indebted to the two excellent companies that kindly accepted my proposal to conduct
my research investigation.
Lean Aerospace Initiative (LAI) made it possible to investigate these two companies in
Japan.
I could not have completed my study at MIT without the full support of my wife, Chiaki,
and my daughter, Niina.
4
TABLE OF CONTENTS
ABSTRACT
3
ACKNOWLEDGEMENTS
4
TABLE OF CONTENTS
5
LIST OF FIGURES AND TABLES
9
CHAPTER 1: INTRODUCTION AND OVERVIEW
1.1 MOTIVATION
17
1.2 GOALS AND OBJECTIVES
17
1.30VERVIEW OF THE REMAINING CHAPTERS
17
21
CHAPTER 2: LITERATURE REVIEW
CHAPTER 3: PRELIMINARY STUDIES
3.1 INTRODUCTION
23
3.2 THE FIRST PRELIMINARY STUDY
23
3.2.1 OBJECTIVE OF THE FIRST CASE STUDY
23
3.2.2 SELECTED PROJECT AND FOCUS
23
3.2.3 DRAWING A VALUE STREAM MAP
24
3.2.4 EVALUATION
25
3.3 THE SECOND PRELIMINARY CASE STUDY
3.3.1 OBJECTIVE OF THE SECOND CASE STUDY
26
3.3.2 SELECTED PROJECT AND FOCUS
27
3.3.3 DRAWING A VALUE STREAM MAP
27
3.3.4 EVALUATION
28
3.4 THE THIRD PRELIMINARY CASE STUDY
3.4.1 OBJECTIVE OF THE THIRD CASE STUDY
29
3.4.2 SELECTED PROJECT AND FOCUS
29
3.4.3 DRAWING A VALUE STREAM MAP
29
5
3.4.4 EVALUATION
30
CHAPTE 4: IMPROVEMENT SUGGESTIONS FOR VALUE STREAM MAPPING
4.1 WAY OF DISPLAYING REWORK
32
4.2 ADOPTION OF SWIM-LANE FORM
32
4.3 SHOWING BOTH PLANNED AND ACTUAL SCHEDLU LES
33
4.4 DISPLAYING INTERRUPTING EVENTS
33
CHAPTER 5: ROOT-CAUSE ANALYSIS DIAGRAM
34
5.1 ANALYSIS OF RELATIONSHIP AMONG DIFFERENT TYPES OF WASTE
5.2 DEVELOPMENT OF ROOT-CAUSE ANALYSIS DIAGRAM WITH NINE PLUS ONE WASTE
34
INDICATORS
5.3 DEFINITIONS OF NINE WASTE INDICATORS AND INVENTORY OF INFORMATION
5.3.1
DEDUCING NINE
WASTE INDICATORS FROM THE
ROOT-CAUSE
ANALYSIS
37
DIAGRAM
40
5.3.2 INVENTORY OF INFORMATION
5.4 ROOT-CAUSE ANALYSIS DIAGRAM FOR NINE WASTE INDICATORS
40
CHAPTER 6: VALUE STREAM MAPPING FOR QUANTITATIVE ANALYSIS OF
PD PROJECTS
6.1 OBJECTIVE
41
6.2 VALUE STREAM MAPPING FOR QUANTITATIVE ANALYSIS OF PD PROJECTS
6.2.1 TIME LINE AND GRIDS
42
6.2.2 PROCESS BOXES -ALLOCATION AND LENGTH
43
6.2.3 BOXES - COLOR CODES
46
6.2.4 ARROWS - COLOR CODES
49
6.2.5 INTERACTIONS
52
6.2.6 CROSS-FUNCTIONAL TASKS
53
6.2.7 INTERRUPTIONS
54
6.2.8 TIME RECORDING
55
6.2.9 WASTE INDICATORS
56
6
CHAPTER 7: HOW TO MEASURE WASTED TIME USING VALUE STREAM
MAPPING
7.1 INTRODUCTION OF THIS CHAPTER
57
7.2 OVERPRODUCTION
57
7.3 WAITING
58
7.4 TRANSPORTATION OF INFORAMTION
59
7.5 OVER PROCESSING
60
7.6 MOTION
61
7.7 REWORK
62
7.8 RE-INVENTION
63
7.9 HAND-OFF
64
7.10 DEFECTIVE INFORMATION
65
CHAPTER 8: INVENTORY OF INFORMATION AND HOW TO MEASURE IT
USING VALUE STREAM MAPPING
8.1 INTRODUCTION
66
8.2 DEFINITIONS OF ROTTEN INFORMATION AND FRESH INFORMATION
67
8.3 HOW INFORMATION GETS ROTTEN
8.3.1 MARKET CHANGE
67
8.3.2 REQUIREMENTS CHANGE
67
8.3.3 TECHNICAL DIFFICULTIES
67
CHAPTER 9: OVERVIEW OF THE RESEARCH INVESTIGATIONS
69
9.1 RESEARCH QUESTIONS
9.2 ABOUT THE COMPANIES AND PROJECTS
9.2.1 OVERVIEW OF THE THREE PROJECTS
70
9.2.2 DIFFICULTIES IN THE PROJECTS
71
9.3 INVESTIGATION SCHEDULE
9.3.1 OVERVIEW OF INVESTIGATION SCHEDULE
72
9.3.2 DETAILED SCHEDULE FOR COMPANY X
72
7
CHAPTER 10: RESULTS OF RESEARCH INVESTIGATIONS 1: ANALYSES ON
NINE WASTE INDICATORS
75
10.1 OVERVIEW OF THIS CHAPTER
10.2 OVERALL RESULTS
10.2.1 NUMBER OF OCCURENCES
75
10.2.2 AVERAGE WASTED TIME PER ONE OCCURRENCE
77
10.2.3 TOTAL WASTED TIME
78
10.2.4 TEMPORAL CHANGES
IN WASTE INDICATOR DISTRIBUTIONS
10.2.5 DISTRIBUTION OF WASTE INDICATORS AMONG ENGINEERS
80
83
10.3 DETAILED ANALYSIS ON EACH WASTE INDICATOR
10.3.1 OVERVIEW
87
10.3.2 OVERPRODUCTION - WASTED ENGINEERING HOURS BY CAUSES
87
10.3.3 WAITING - WASTED ENGINEERING HOURS BY CAUSES
89
10.3.4 TRANSPORTATION - WASTED ENGINEERING HOURS BY CAUSES
90
10.3.5 OVER PROCESSING
92
10.3.6 MOTION
98
10.3.7 REWORK
102
10.3.8 RE-INVENTION
109
10.3.9 HAND-OFF - WASTED ENGINEERING HOURS BY CAUSES
109
10.3.10 DEFECTIVE INFORMATION
110
10.4 SUMMARY OF ANALYSIS ON NINE WASTE INDICATORS
112
CHAPTER 11: RESULTS OF THE RESEARCH INVESTIGATIONS 2: ANALYSES
ON INVENTORY OF INFORMATION
11.1 OVERVIEW OF THIS CHAPTER
114
11.2 NUMBER OF OCCURENCES OF INVENTORY
114
11.3 AVERAGE INVENTORY PERIOD
116
11.4 TOTAL INVENTORY TIME
117
11.5 IMPLICATIONS
117
11.6 CLASSIFICATION OF IDENTIFIED INVENTORY
119
11.7 DISTRIBUTION OF INVENTORY TYPES AMONG ENGINEERS
140
11.8 ANALYSIS ON INVENTORY OF INFORMATION BY ITS TYPES
11.8.1 NUMBER OF OCCURENCES
142
8
11.8.2 AVERAGE INVENTORY PERIODS
144
11.8.3 TOTAL INVENTORY TIME
146
11.8.4 OVERALL DISCUSSION
146
11.9 ROTTEN AND FRESH INVENTORY
11.9.1 RATIO OF ROTTEN INVENTORY AND TIME
150
11.9.2 RATIO OF LOST VALUE IN ROTTEN INFORMATION
153
11.9.3 MONTHLY INTEREST RATE CALCULATION
154
11.9.4TYPES
OF
ROTTEN
--
INVENTORY
DISTRIBUTION
OF TYPES
OF
ROTTEN
154
INVENTORY
155
11.10 SUMMARY OF THIS CHAPTER
CHAPTER 12: FUTURE WORK
12.1. NINE WASTE INDICATORS
156
12.2 INVENTORY OF INFORMATION
156
12.3 SUBSTITUTING TASK INVENTORY FOR INFORMATION
158
12.4 ARE TOC'S THREE METRICS SUFFICIENT?
159
12.5 SHOWING WASTED TIME EXPLICITLY IN VALUE STREAM MAPS
159
12.6 EXPLORATION OF ENGINEER UTILIZATION LEVELS
160
CHAPTER 13: CONCLUSIONS
161
APPENDIX I: EXECUTIVE SUMMARY
163
APPENDIX II: THE ROOT-CAUSE ANALYSIS DIAGRAM
173
BIBLIOGRAPHY
205
9
LIST OF FIGURES AND TABLES
FIGURES
Figure 2.1 Ten Categories of Waste in Product Development (Bauch, 2004)
22
Figure 3.1 Value Stream Map for One Designer's Activities with Waste Defined by
24
McManus (2004) and Morgan (2002) -Continued to Figure 3.2
Figure 3.2 Value Stream Map for One Engineer's Activities with Waste Defined by
25
McManus (2004) and Morgan (2002) -Continued from Figure 3.1
26
Figure 3.3 Simplified Value Stream Map with Rework with Going-Back Arrows
28
Figure 3.4 Value Stream Map for Whole Railway Vehicle Development Project
Figure 3.5 Value Stream Map for a MIT Student Product Development Project - Continued
30
to Figure 3.6.
Figure 3.6 Value Stream Map for a MIT Student Product Development Project - Continued
31
from Figure 3.5.
Figure 4.1 Showing Rework in a Separate Process Box
Figure 4.2 Way of Showing an Interrupting Event
32
33
Figure 5.1 Analyses of Relationships among the Categories of Waste Defined by Morgan
and McManus - The Categories without the Name of Morgan or McManus
were added by the Author.
36
Figure 6.1 Time Line and Grids
Figure 6.2 Allocations of Adjacent Phases
Figure 6.3 Allocation of a Process Box for Rework
Figure 6.4 Allocations of Process Boxes for Different Functions
Figure 6.5 Beginnings and Ends Process Boxes- Beginnings and Ends of the Process
Should Match the Time Line at the Top of the Value Stream Map
Figure 6.6 Blue, White, and Pink Boxes
Figure 6.7 Using White Boxes for Showing Original Schedule
Figure 6.8 Displaying Review and Testing Processes
Figure 6.9 Displaying Rework
10
42
43
43
44
Boxes
45
46
47
48
48
49
Figure 6.10 Displaying Over Processing
Figure 6.11 Timely Information Transfer and Delayed Information Transfer - Information
50
Stored for a Specific Period is Distinguished by Using Green Lines
50
Figure 6.12 Displaying an Interruption
51
Figure 6.13 Different Types of Hand-Offs
52
Figure 6.14 Displaying Bi-directional Information Exchanges
53
Figure 6.15 Displaying Cross-Functional Tasks
54
55
56
Figure 6.16 Displaying Interruptions
Figure 6.17 Displaying Spent Time
Figure 6.18 Displaying Wasted Time
Figure 7.1 Measuring Time Spent on Overproduction - A Hatched Process Box Mean
57
Overproduction
58
Figure 7.2 Measuring Time Spent on Waiting
59
Figure 7.3 Measuring Time Spent on Transportation
60
Figure 7.4 Measuring Time Spent on Over Processing
61
Figure 7.5 Measuring Time Spent on Motion
62
Figure 7.6 Measuring Time Spent on Rework
63
Figure 7.7 Measuring Time Spent on Re-Invention
64
Figure 7.8 Measuring Time Spent on Hand-Off
65
Figure 7.9 Measuring Time Spent on Defective Information
Figure 8.1 Rotten Information Due to Technical Risk
68
Figure 10.1 Normalized Occurrences of Waste Indicators per 50 Engineering Weeks in
76
Projects A, B, and C
Figure 10.2 Wasted Time per Each Occurrence of a Waste Indicator in Projects, A, B, and C
77
Figure 10.3 Normalized Total Wasted Time per 50 Engineering Weeks and Waste Indicators
79
Figure 10.4 Temporal Changes in Waste Indicator Distribution in Project A
Figure 10.5 Temporal Changes in Waste Indicator Distribution in Project B
Figure 10.6 Temporal Changes in Waste Indicator Distribution in Project C
11
80
81
82
Figure 10.7 Waste Indicator Distributions by Engineer (Project A)
84
Figure 10.8 Waste Indicator Distributions by Engineer (Project B)
85
Figure 10.9 Waste Indicator Distributions by Engineer (Project C)
86
Figure 10.10 Normalized Waste Time on Over Production per 50 Engineering Weeks and
the Corresponding Causes
88
Figure 10.11 Normalized Waste Time on Waiting per 50 Engineering Weeks and The
Corresponding Causes
89
Figure 10.12 Normalized Waste Time on Transportation per 50 Engineering Weeks and the
Corresponding Causes
90
Figure 10.13 Part of the Root-Cause Analysis Diagram of Transportation of Information
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
91
10.14 Normalized Waste Time on Over Processing per 50 Engineering Weeks and
The Corresponding Causes
94
10.15 Part of the Root-Cause Analysis Diagram of Over Processing
95
10.16 Wasteful Information Flow without Effective Verification Processes
97
10.17 Normalized Waste Time on Motion per 50 Engineering Weeks and The
Corresponding Causes
98
10.18 Part of the Root-Cause Analysis Diagram of Motion
100
10.19 Example of a Process with Frequent Design Reviews - Engineer KZ's design
Process in Project C
101
10.20 An Example of Rework in Value Stream Map (Project A, Engineer T)
102
10.21 Normalized Waste Time on Rework per 50 Engineering Weeks and The
Corresponding Causes
103
10.22 Part of the Root-Cause Analysis Diagram of Motion
106
10.23Wasteful Information Flow without Effective Verification Processes
107
10.24 Changes in Rework Time (Projects A and B)
108
10.25 Changes in Rework Time (Project C)
108
10.26 Normalized Waste Time on Hand-Off per 50 Engineering Weeks and the
Corresponding Causes
109
10.27 Normalized Waste Time on Defective Information per 50 Engineering Weeks
and Causes
110
10.28 Company Y's Relationship with Users - There's Virtually No Communication
Channel with Users
112
12
Figure 11.1 Number of Occurrences of Inventory of Information per Week
Figure 11.2 Average Periods of Inventory
Figure 11.3 Total Inventory Time per Engineering Week
Figure 11.4 Example of Type 1 Inventory
Figure. 11.5 1328, Inventory of Information at the Center of This Figure was Caused
Interrupting Event from Inside of the Project (Engineer Y, Weeki 1)
Figure
Figure
Figure
Figure
115
116
117
120
by an
121
122
11.6 Example of Type 2 Inventory
11.7 Example of Switching to Higher-Priority Task outside of the Project System-Level Services Task was Interrupted by a Support Work Outside of
123
Project A
124
11.8 Waiting for Information from another Task
11.9 Example of Inventory (3)-l - The Two Tasks Circled in This Figure were Both
125
Testing Processes.
Figure 11.10 Example of Inventory (3)-2 - the Task in the Dashed Circle was Left
Untouched until the Downstream Task Got All the Information It Needed.
126
127
Figure 11.11 Example of Inventory Caused by Review/ Testing Work
Figure 11.12 Example of Inventory Caused by Day Off - PMU DC CAL Design/
128
Implementation Task was Interrupted by a Week Off.
129
Figure 11.13 Inventory of Information Caused by Maintenance of Documenting
Figure 11.14 Example of Inventory of Information Caused by Maintenance of
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
130
Documenting
131
11.15 Inventory of Information Caused by Rework Discovery
132
11.16 Example of Inventory of Information Caused by Rework Discovery
11.17 Example of Inventory of Information Caused by Other Engineer's Availability
133
11.18 Inventory of Information Caused by Downstream Engineer's Availability 134
11.19 Example of Inventory of Information Caused by Downstream Engineer's
135
Availability
136
11.20 Inventory of Information Caused by Waiting for an Answer
11.21 Example of Inventory of Information Caused by Waiting for an Answer 137
11.22 Example of Inventory of Information Caused by Ambiguous Information 138
13
Figure 11.23 Example of Inventory of Information Caused by Limited Availability of
Tool/Board/System
139
Figure 11.24 Distribution of Types of Inventory (Project A)
140
Figure 11.25 Distribution of Types of Inventory (Project B)
141
Figure 11.26 Distribution of Types of Inventory (Project C)
142
Figure 11.27 Normalized Occurrences of Inventory of Information per 50 Engineering
Weeks and the Corresponding Types
143
Figure 11.28 Average Inventory Periods and the Corresponding Types
145
Figure 11.29 Total Inventory Time and the Corresponding Types
147
Figure 11.30 Unsynchronized Manufacturing Process Described in "The Goal" (Goldratt,
1984).
148
Figure 11.31 Unsynchronized Development Process of Project A
149
Figure 11.32 Ratio of Rotten Inventory of Information in Number (Project A)
150
Figure 11.33 Changes in Ratio of Rotten Inventory of Information with Time (Project A)
151
Figure 11.34 Trend Line of Changes in Ratio of Rotten Inventory with Time (Project A)
152
Figure 11.35 Changes in Rework Ratio with Time
153
Figure 11.36 Relationships between Ratio of Rotten Inventory and the Corresponding
Types
155
Figure 12.1 Interest Rate of Information Inventory
156
Figure 12.2 Reduction of Released Product's Value
157
Figure 12.3 Counting Task Inventory with a Value Stream Map (Project B) - Task
Inventory Can be Calculated by Counting Green or Red Lines Crossing a
Day.
158
Figure 12.4 Measuring Time Spent on Overproduction - A Hatched Process Box Mean
Overproduction (Same as Figure 7.1)
159
Figure 12.5 Time Spent on Tasks Shown in a Value Stream Map
160
(Project A, Engineer Y)
Figure A-I An Example of Root-Cause Analysis Chart
Figure A-2 An Example of the Value Stream Map for Quantitative Analysis
14
164
165
166
Figure A-3 Relationship between Wasted Time and Nine Waste Indicators
166
Figure A-4 An Example of Identified Problem
167
Figure A-5 Average Time Spent on One Occurrence of Rework
Figure A-6 Total Inventory Time per Engineering Week: Number of Engineers in Projects A,
168
B, and C are 6, 6, and 5 Respectively.
169
Figure A-7 Total Inventory Time and the Corresponding Type
Figure A-8 Trend Line of Changes in Ratio of Rotten Inventory with Time (Project A) 170
170
Figure A-9 Changes in Rework Ratio with Time
15
TABLES
Table 5.1 Comparison of the Definitions of Waste
Table 5.2 Definitions and Examples of Nine Waste Indicators
35
Table 9.1 Description of the Three Investigated Projects
70
Table 10.1 Each Engineer's Profile
Table 10.2 Each Engineer's Profile (Project B)
Table 10.3 Each Engineer's Profile (Project C)
84
85
86
Table A-I Nine plus One Waste Indicators
163
16
39
CHAPTER 1 INTRODUCTION AND OVERVIEW
1.1 MOTIVATION
Although different types of waste in product development have been suggested, there have
been no research investigations in determining what types of waste are more prevalent than
others in terms of wasted engineering time. Although there have been substantial amount of
literature on how to successfully manage product development projects, there is no
practical tool with which project managers can quantitatively analyze their unsuccessful
projects. For these reasons, there is no effective project management tool that enables
product development project managers to know how much each factor quantitatively affects
their product development project performances. For example, they may attribute their
product failure to late specifications/ requirements changes, but they cannot estimate how
much those changes affected the overall project performances. Therefore, it is difficult for
them to know what the right thing is to improve their product development processes.
1.2 GOALS AND OBJECTIVES
The goal of this research is to develop a process for continuous creation of lean value in
product development organizations. Creation of lean value here means realizing value with
minimum wasteful process.
To achieve this goal, the objective of this research was determined to develop ideas and
methodologies of lean product development into tools and processes that can help product
development organizations (1) identify and measure the waste in their teams' processes; (2)
identify causes and measure their impacts on PD processes; and (3) finally learn the best
strategies to pursue to improve their PD processes.
1.3 OVERVIEW OF THE REMAINING CHAPTERS
Different types of waste were reexamined and nine plus one waste indicators were selected.
Value stream mapping was optimized for quantitative measurement of wasted time.
Exploration of causal relationships among these waste indicators and various types of
causes for waste lead to a comprehensive diagram that can be used for identifying root
causes for waste. To test the supposition that these can be applicable for quantitative
analysis of product developments projects, three case studies were performed.
17
Chapter 2 takes a look at lean manufacturing, and how it has been developed into lean
product development.
Three preliminary case studies were performed in chapter three, in which value stream
mapping's applicability for quantitative measurements of wastes suggested in literature on
lean product development was evaluated. Several problems were identified. These
problems were addressed in chapter 4.
Different types of waste that have been suggested in studies in lean product development
are compared in chapter 5 by exploring causal relationships among each waste. This study
was finally developed into the root-cause analysis diagram by adding more types of waste
identified in papers and books, and the preliminary case studies.
Chapter 6 is a how-to manual for drawing value stream maps for quantitative measurement
of waste. Many features of value stream mapping that were unnecessary for the purpose
were eliminated.
A methodology for measuring waste using nine waste indicators is described in chapter 7.
Inventory of information can be measured by the methodology described in chapter 8.
These methodologies were applied in the case studies covered in the following three
chapters.
Chapter 9 introduces the case studies in three industrial product development projects.
Chapter 10 discusses the quantitative analysis results obtained using nine waste indicators.
Three waste indicators detected significantly more waste than the other six. The results also
revealed rework takes more time at the end of projects than at the beginning of them.
Chapter 11 discusses results obtained by identifying inventory of information. In a project
in which market and technical risks are high, inventory of information became bad at the
rate of six percent per month. The analysis of the results described in chapters 10 and 11
suggests that the tools and methodologies developed in this research can show how
engineers' time is wasted in each specific project, implying these can be used for improving
each project's processes.
18
Chapter 12 concludes this research.
19
1.4 NOTE
This thesis contains some figures in color, although the author tried to convey all the
information in black and white whenever possible. The full-color version is available online
at Lean Aerospace Initiative (LAI)'s website: lean.mit.edu.
20
CHAPTER 2 LITERATURE REVIEW
The concept of "lean" was first applied to product development by introducing ideas and
tools of lean manufacturing. Wormack and Jones (1996) defined five lean principles,
"specifying value," "identify the value stream," "flow," "pull," and "striving for
perfection." Two research topics, definition of waste and practical way of value stream
mapping have been focused on by many scholars and product development practitioners,
based on the idea that addressing these topics lead to realization of the five lean principles.
From the perspective of waste, Wormack and Jones introduced nine categories of waste by
adding two new categories to Toyota's seven categories of waste in manufacturing. Slack
(1999) tried to prioritize the nine types of waste by conducting surveys of product
development organizations, questioning each category's frequencies. He also analyzed each
category's effect on value.
The definition of categories of waste has continuously been discussed by exploring the
differences between manufacturing and product development environment. Morgan (2002)
dramatically changed the definition of waste from the perspective of systems engineering.
Based on the idea that unsynchronization leads to low performance in product development
processes, he introduced eleven categories of waste, replacing all but one: waiting.
Recognizing interdependency among the categories of waste defined by forerunners, Bauch
(2004) re-defined ten categories of waste by analyzing interactions among the categories.
Value stream mapping has also been tried to apply to product development processes as
product development value stream mapping (PDVSM). Early versions of PDVSM,
inherited many features in value stream mapping for manufacturing, were not capable of
displaying activities specific to the product development environment such as iteration and
multiple tasking. Morgan (2002) improved PDVSM by making each process box' length
proportional to the time spent on it. Although this suggestion clearly differentiated PDVSM
from ordinal process maps in that unsynchronization became visible, how to display
iteration and multiple tasking remained to be solved.
21
.-MO-
11111w-
--.
1
--
..
Obvious Waste drivers
-Sub-categories -
Stop Ago t"Tak
104 Wst
r
0r
..........
W*04 sit
U
U
I
LOW
I Pow
UWW90WWd
I
, i ,-
I
OdAdmb dft%**
ralm
am rwft
ID
"An
Figure 2.1 Ten Categories of Waste in Product Development (Bauch, 2004)
The definitions of waste have not been explicitly utilized for displaying waste in value
stream maps until Graebsch (2005) applied Bauch's definition to his microscopic case
studies of ongoing MIT student projects. He successfully measured occurrences of waste by
displaying it in value stream maps, making it possible to measure a frequency of each
category of waste on a value stream map. This achievement raised the following research
research questions:
1.
Can value stream mapping be used for measuring wasted time?
2. Can value stream mapping be applied to analyses of industrial product development
processes?
22
CHAPTER 3 PRELIMINARY STUDIES
3.1 INTRODUCTION
To evaluate value stream mapping's applicability for measuring wasted time, three
preliminary case studies had been performed.
3.2 THE FIRST PRELIMINARY CASE STUDY
3.2.1 OBJECTIVE OF THE FIRST CASE STUDY
The objective of this case study was to evaluate value stream mapping's applicability to
measuring wastes defined by McManus (2004) and Morgan (2002).
3.2.2 SELECTED PROJECT AND FOCUS
The first project chosen for this evaluation was a railway vehicle constructor's development
process. The railway vehicle had been developed by three design teams: body,
power/electronics, and bogie teams. For simplicity, only a mechanical designer's design
process had been tracked, based on value stream mapping techniques proposed by Morgan
and McManus. The designer's task was to re-design the structure of the current model of
railway vehicle by performing finite element analysis. The structure change had affected
the other teams design, causing cross-team iteration. The project was finished in 2002.
23
W1NV3 Waiting
W1 Hand-off
Legend
Mc~anus(2004)W4
Tranacdon
Mran (02
3
1 Redundant Tak
Both
W2 Usnhoie
Receive Unofficial Order ets
with Rough Specification
OutsouFlEd
FE Task
Coort nati
ADlz
Desig er
Products' Layo
est ie
iia
(2
WRUest
Make a Contract
I
Ask Tokyu Cr
aou
CAD Micro CADAM)
Resus
WpUnnecessaoy
recretTak
W4 Ta nsaction
Waste
No
ovrted automatically
Current
Devlop
Surfce (Solidworks)
Moio
WS Trans p, daJn
Curren,
Vehic le's
Load Test Results.
VWY5
bo
Study (Go to
See Existing Similar
Products in Use)
5Fiekd
Body
Struct re
Team
-nvestigate
4
velop current
vehic l's FE model
(NASTRAN)
Compare Tet
Results and
FEA Results
Rfe
EMde
3oda
W5 Transoitation
Define Tentative
Body Stucture
for
:Set Guideline
Anyzn
EA
|Res
Document
bted
ults
W T
ry
Hold DR with Production
Management Sec., Manufacturing"
Sec., and Purchasing Sec.
Assess Weight
of Each Element
Expertise
3
SeLadBndy
Cniin
for New Veh ic les
W5 Transportatio3
Develop Basic FEA Skill
30
Select Power
Electronics Equipments
Powe
Elermis
Provide information of weight and position of center of gravity of the equipments
H11~
31
Bogte
Team
Set Basic Specification
of Bogir
Figure 3.1 Value Stream Map for One Designer's Activities with Waste Defined by
McManus (2004) and Morgan (2002) -Continued to Figure 3.2
3.2.3 DRAWING A VALUE STREAM MAP
Value stream maps created in the first preliminary case study are shown in figures 3.1 and
3.2. In this case study, process boxes' lengths were not made proportional to the time spent
on them because the remaining data of the development process did not have detailed
information about time spent on each task. Based on the designer's memory, which was the
only available resource, roughly estimated waste time was put on the value stream map.
This map was created through the following steps.
Step. 1. Draw all process boxes and add information flows.
Step. 2. Identify wastes in the lists of Morgan's and McManus'.
24
Step. 3. Estimate roughly wasted time spent on each waste.
More than a week
Several days
A day
A few hours
An hour
Several minutes
3-4
t tults
Ge.raet
3-6
Analyze Result
Import DATA
HOoW1-ofteven
W1 3vent
t
Wab
an t
M
W4
Tradaction
W
Customeron:
nerw
ate
Scral
A
Fgure3.2ValueStreamMap for
One Engineer'sortis
r
t
e
Aivi
with Wel
*held occasionail
5
4
-29
Ths wModify
Preliminary Structure Design
~
csu
!-------,
2
cu
n
b
lyl ------
Sec., Purchase Sed
(Screeni"oa
|otmufctisMentgmte Sec
(20)Cntnedfo
'
Figurde3.
Wcurnc eoary
by
3w
T
Model
subuctupo
McAnu (204
aihEin Mrorgans
whWn
(Set Boundary/Load Conditions,
Screen
D
Initial Ideas)
Gsaiyte
MReview
follo
|Wff
Instudreorkwsshon
ths cas
Fo
eaplinfgres 3.1 nd .2,tss
W13Q"n&Y!MMU3
Sbyuing anaro that
p wde
bac to-th-rewrkedtask
Detail Structure D~esign
between- (2'n 2)wr eetdsvrltms
Figure 3.2 Value Stream Map for One Engineer's Activities with Waste Defined by
McManus (2004) and Morgan (2002) -Continued from Figure 3.1
3.2.4 EVALUATION
2. ~
~~
~
~
~
~
~
Processen
boe'odeehudbetesmeachi.ata)ccrecs
~~
Pouto
In this case study, rework was shown by using an arrow that went back to the reworked task.
For example, in figures 3.1 and 3.2, tasks between (2) and (20) were repeated several times.
This way of showing rework made it impossible to satisfy the following rules suggested by
Morgan.
1. Process boxes' lengths should be proportional to the time spent on them.
2. Process boxes' order should be the same as their actual occurrences.
This problem is obvious when some downstream tasks are affected by an occurrence of
25
rework like in figure 3.3. In this figure, task 3, which was started after task 2's start, appears
before task 2, which does not satisfy the second rule above. Thus, using going-back arrows
makes it impossible to follow Morgan's two rules.
Another problem is that using a going-back arrow makes it impossible to display how a
project's schedule is affected by an occurrence of a wasteful activity, such as making
defective information. For example, it is not obvious in figure 3.3 whether task 2 was
reworked because of defective information received from task 1, or it was reworked
because of defective information made inside of task 2. Thus, using a going-back arrow
makes it unclear how other tasks are affected by a wasteful activity. For the same reason,
measuring waste is also difficult when a going-back arrow is used.
Week 1
Week 2
Week 3
i
I
Week 4
-- b
Time Line
T
Task 3
Time
spent
on
ask 5
20
->40
Task 5
~
40
the original work
Task 1
Task 2
80(4)
1
40 (20)
-
'p
r
Task 4
20 (10)
Going-back arrow
Total time spent on task 1
(original work +rewor )
Figure 3.3 Simplified Value Stream Map with Rework with Going-Back Arrows
3.3 THE SECOND PRELIMINARY CASE STUDY
3.3.1 OBJECTIVE OF THE SECOND CASE STUDY
The objective of this case study was to evaluate value stream mapping's applicability to a
whole product development project.
26
3.3.2 SELECTED PROJECT AND FOCUS
The same railway vehicle development project was selected for the second case study. This
time, the whole development processes were selected as the scope of the value stream map.
3.3.3 DRAWING A VALUE STREAM MAP
Figure 3.4 shows the value stream map drawn in this preliminary case study. Contrary to
the first case study, process boxes' lengths were made proportional to the time spent on
them, although the accuracy was limited. After several trials, the swim-lane form was
finally chosen.
27
3.3.4 EVALUATION
Adoption of swim-lane form made it possible to draw a value stream map without making
it too complicated.
VSM of Railway Vehicle Development
interaction with suppliers is not described in this map.
Se qtIMi
Customer
Desig
Sec..
Segt
7n.
vi~~iii
-4
Target
SSetcificatin
Storage of Expertise
DR held by Customer
Coinromi
Revise Specification
----------Body~str.
Team
Prelimin
tudy
Gener e
MultipleAte n
Tent
s
imnary
.
±
y
.
m-----------
dy Str
uilt
Te
Pi
Preliminary Study
P
urcas
Production
*
Mgt. Sec.
..
I
Schedule Development
and Production (Rough)
stem
-Plan
P
sing
*
l
Schedule
ati
Is
Processing &
ffg. Center
ign (w/ Varibus
ies)
D
lopr
n Bogie
I
-
It
anning
Manufacturing Tools P
(Machines/Dies/Robots)
Mfg.
;enter.
V.
Body Structure
Center.
F
s
Manufacturing Tools Planning
(Machines/Dies/Robots)
Robot Section
4
*c
ystem
Design Bog'
Gneate
;4- ple
Ate
Machinery/
>arts
Se
:1ncepDesiga
Bogie
ao
Design Detailed I
Design Basic Str. (FEA
Study)
Draw Kento-Z s ry-and
I_
enbrate
le Aftematives
Concept Desil
Electrics &
Plumbing
Team
I
. a.
."..
...........
..
Iting Center
Bogie Mfg.
Center
a
Figure 3.4 Value Stream Map for Whole Railway Vehicle Development Project
28
3.4 THE THIRD PRELIMINARY CASE STUDY
3.4.1 OBJECTIVE OF THE THIRD CASE STUDY
The objective of this case study was to test the applicability of value stream mapping to
measuring waste inside of each task.
3.4.2 SELECTED PROJECT AND FOCUS
A student product development project was chosen as the target of the third case study. The
project was a one-semester-long project in which undergraduate students developed a
unique product, observing a strictly enforced schedule with several milestones set by
faculty. The team consisted of eighteen students. They were divided into two sub teams
during the concept development phase, each of them developing different mock-ups. After
the "mock-up review" milestone, the more promising one was selected and the sub teams
were combined into a big team.
3.4.3 DRAWING A VALUE STREAM MAP
Because the objective of this case study was to measure waste only within process boxes,
information flows were not drawn in the value stream map. Instead, both planned and
actual processes were drawn to make schedule slips visible. As a result, the value stream
map (figures 3.5 and 3.6) became similar to a Gantt chart. The tracked period included four
milestone reviews including the mock-up review. Each task had two boxes in the value
stream map: the upper one being the original schedule and the lower one being the actual
process. Rework processes were distinguished by being hatched. In this case study, process
boxes' lengths were precisely made proportional to the period between the start and end
dates. Instead of using wastes defined by McManus and Morgan, nine waste indicators
introduced in chapter 5 were used.
29
Found a Possibly
More Promising
Solution
Comprormise in
FeatureDecided
Unrealistic features pointed out
10)20
10/13
,P
Mockup
1
Lab
La_1
-11
Selcton
10J26
Team A
11 2
schedu t pres ;ure (No iteration
ock-Wp
Wor Perceived to
Rework
be C Dmolele
a
Lab
Rework
lutualLy
epen lent
asks
Overost effort was
Processirtg
Prooaesg on JLst wasted
- --- -- -- --- -
VEME977-777M
61
Srvy
u
eived to
te
was poss
I.
Feasiblity Araysis
11/10
RevieV
Perce ived to
9Complet
mive
4n(wd
Customer
fork
6*
Rework
lp
thidr
P*
)
Model
NZWENEW11,
0
ndiscovered i mork
Root IWe
N
Root
Team B
Lab
I-Rework (more focused)
Undscovered rewr rrk
. 131
Assembly
Finel Down
undiscog
I i I I Wrmpawlr 1.1'1_1 J - __
~118
V
10121
One root caus
triggered man)
wastes!
Draw a waste
for this.
0/1
10/17
7
Work Perceived to
be Complete
Figure 3.5 Value Stream Map for a MIT Student Product Development Project Continued to Figure 3.6.
3.4.4 EVALUATION
In this case study, all rework took more time than the original work. One reason for this
phenomenon was that scope of the tasks extended as students identified several problems
through manufacturing process of a mock-up. However, there was another reason: the
students did not work as intensively as they had done in the original work: the tasks had not
been worked on all the time. This situation corresponds to today's prevalent product
development environment in which the same engineers are shared by some projects. And,
generally, the sizes of impacts from outside of the project fluctuate. Possible problems
caused by impacts from outside of the project are the following:
1. Project delays due to low availability of engineers.
2. Information loses its value even while it is not worked on because of risks including
30
market risk (see chapter 8).
Therefore, even when a value stream map's focus is one project, impacts from outside of
the focused project should be displayed explicitly somehow.
10/13
10/20
10/27
10/21
LaFinal
Donaabctn
SMockup
11/3
1118
11/10
11/12
11/17
Lab
Assey Mdl
Lab
InCla
Lab
Revipw
'AX1PW
---------
I IIIProduct Cotwract(MkwtlCutomrwrArvoyads)
Wol k Percei /ed to
be Complek
Deftet
Product GOOMetry
77
aft
R
DEIIu MO4IIiS mid InWtf
OW
procankv.
Watn
gfor
17"
us
itusev
Detie Des n
ai
inmtpoon on samytreguh4ons
Prep
lass
Figure 3.6 Value Stream Map for a MIT Student Product Development Project Continued from Figure 3.5.
31
CHAPTER 4 IMPROVEMENT
STREAM MAPPING
SUGGESTIONS
FOR
VALUE
4.1 WAY OF DISPLAYING REWORK
The problem about representation of rework (3.2.4) can be addressed by displaying rework
with a separate box (figure 4.1). This makes it possible to satisfy the two rules suggested by
Morgan (2002) (see 3.2.4). In order to make it easy to identify the original task of the
rework, only the process boxes for rework should be along the same line with that of the
original task.
Only the same tasks should be
along the same line.
Figure 4.1 Showing Rework in a Separate Process Box
4.2 ADOPTION OF SWIM-LANE FORM
Generally, hand-offs across functional groups take more time and effort than they do within
a functional group. In the second preliminary case study, swim-lane value stream mapping
could successfully visualize this difference. Adoption of this swim-lane form was also
effective for keeping the value stream map organized in spite of high complexity of
communications across many functional groups. Additionally, when used in combination
with the method suggested in 4.5, Swim-lane value stream mapping made it possible to
visualize how unsynchronization happened due to interrupting events.
32
4.3 SHOWING BOTH PLANNED AND ACTUAL SCHEDLULES
In the third preliminary case study, interviews with students were performed several times.
When students were asked if they had found any wasteful activity in their development
process with the value stream map displaying only actual processes, it was difficult to get
enough information related to waste. After adding the original schedule information to the
value stream map, however, it became significantly easier. Thus, showing both planned and
actual schedules turned out effective for identifying wasteful activities through interviews.
4.4 DISPLAYING INTERRUPTING EVENTS
As indicated in the third preliminary case study, engineers are sometimes occupied with
tasks from outside of the project, causing project delay. Such interruption is one of major
sources of project delay as well as waste inside of the project: in order to accurately
measure waste derived from activities inside of a project, it is necessary to know whether
delay is caused by activities inside of the project or not. Interrupting event can explicitly be
shown by using a sign shown in figure 4.2.
An Ean Ited Task
out of the Project
Figure 4.2 Way of Showing an Interrupting Event
33
CHAPTER 5 ROOT-CAUSE ANALYSIS DIAGRAM
5.1 ANALYSIS OF RELATIONSHIP AMONG DIFFERENT TYPES OF WASTE
Table 5.1 compares several definitions by forerunners. Toyota's seven categories of waste
have been revised to address waste in product development processes. Wormack and Jones
(1996) modified Toyota's definition by adding two categories, "complexity," and "time
lag," and removing over processing. Although these two added categories are not in
Toyota's definition, they are the ones that are not peculiar to product development
processes. In addition, "time lag" is related to over processing in that time lag causes over
processing - time lag means rework discovery time, and long rework discovery time causes
over processing (on defects). Morgan dramatically revised the definition by replacing all
but "waiting.", based on the systems perspective. Bauch (2004) revised these definitions by
analyzing interactions among each category of waste. The total number of all the categories
referred to above sums up to twenty three.
5.2 DEVELOPMENT OF ROOT-CAUSE ANALYSIS DIAGRAM WITH NINE PLUS
ONE WASTE INDICATORS
Because one of this research's objectives were making it possible to measure waste in
product development processes, using all the categories, which were twenty three in total,
in Table 5.1 was unrealistic. To deduce a frugal set of categories of waste, the causal
relationships among the categories in table 5.1 were analyzed. Figure 5.1 shows an example
of this analysis, in which the definitions by Morgan (2002) and McManus (2004) were
compared. This figure reveals that most of Morgan's categories were causes for the waste
categories defined by McManus, which basically inherited Toyota's seven categories of
waste. For example, "lack of system discipline (Morgan)" causes "over production
(McManus),"
"unsynchronized concurrent tasks (Morgan),"
and "ineffective
communication (Morgan)." This analysis had been expanded by incorporating other waste
definitions and various factors of low performances in product development processes
found in papers and books. And, it had been improved through the preliminary case studies
discussed in chapter 3. The complete result of this analysis is shown in 5.4: Root-Cause
Analysis Diagram.
34
Table 5.1 Com parison of the Definitions of Waste
1
Toyota's seven
wastes (Ohno,
1978)
Waiting
2
Transportation
3
Over Processing
Wormack and
Jones(1996)
Morgan (2002)
McManus (2004)
Bauch (2004)
Wait Time
Waiting
Waiting
Waiting
Transport
-
Transportation
Transport/ Handoffs
Excessive
Pcessivg
--
Processing
Over Processing
__________
4
Inventory
Inventory
-
Inventory
Inventory
5
Defects
Defects
-
Defects
Defects
6
Motion
Movement
-Unnecessary
-
Motion
Movement
Over Production
Overproduction/
Unsynchronized
Processes
-
Transport/ Handoffs
7
Over Production
Overproduction
8
-
Complexity
-_-_-
9
-
Time Lag
-_-_-
10
-
11
-External
12
-
-
Transaction
-
13
-
-
Re-invention
-
14
-
-
Lack of System
Lack of System
Discipline
Discipline
15
-
-
High Process and
16
-
-
System Over
17
-
-
Expediting
-
-
18
-
-
Large Batch Sizes
-
-
19
-
-
Redundant Tasks
-
-
20
-
-
Stop-and-Go Tasks
-
-
21
-
-
22
----
23
-
-
Limited IT Resources
Hand-Offs
Quality
Enforcement
Re-Invention
Arrival Variation
Utilization
Unsynchronized
Concurrent Tasks
Ineffective
Communication
-
35
......
...
...
. .....
C"
Au
Effec t
HighProcessand
Arrival Variation
(Morgan-W7)
Large Iatch Sizes
(Mor n-W9)
System Over Utilization
and Expediting
(MorMgan-Wn)
Waiting
((Mnus
)
Stop-and-Go Tasks
Morgan-W11)
Inventory
McManus-W2
Over Production
(McManus-4)
an-W6a
MMgM
Redundant Tasks
(Morgan-W10)
Unsynchronized
Concurrent T
(Morma -)
Defects
(McManus-W7)
Ineffective Communication
(Morgan-W13)
Re-Invention Waste
(Morgan-W6)
Excessive Processing
I(Md~anu-W
Transaction Waste
(Morgan-W4)
External
Quality Enforcement
(Morgan-W2)
Transportation
(McManus-W5)
Unnecessary Motion]
(McManus-WS)
Hand-Offs
(Morgan-W1)
Figure 5.1 Analyses of Relationships among the Categories of Waste Defined by Morgan and McManus - The
Categories without the Name of Morgan or McManus were added by the Author.
36
5.3 DEFINITIONS OF NINE WASTE INDICATORS AND INVENTORY OF
INFORMATION
5.3.1 DEDUCING NINE WASTE INDICATORS FROM THE ROOT-CAUSE ANALYSIS
DIAGRAM
The root-cause analysis diagram is shown in 5.4. The rightmost categories in the diagram
are root causes, and leftmost ones, effects. From the perspective of measurement, desirable
categories of waste are the ones that can easily be identified and the wasted time measured.
It was found that effects are easier to measure than their causes. For example, wasted time
on "waiting" can be measured by measuring an engineer's waiting periods. However,
wasted time on "system over utilization" is difficult to measure; "System over utilization is
the root cause for waiting in figure 5.1. Therefore, the nine leftmost categories, which are
effects, were chosen as metrics of waste in product development processes. They are named
waste indicators because they are not causes for waste, but indicate that time is wasted for
some reasons.
NINE WASTE INDICATORS
1. OVERPRODUCTION
2. WAITING
3. TRANSPORTATION
4. OVER PROCESSING
5. MOTION
6. REWORK
7. RE-INVENTION
8. HAND-OFF
9. DEFECTIVE INFORMAITON
Rework is the one that had neither been identified by the forerunners in Table. 5.1. It was
added by the author because it has frequently been pointed out as indicator of low
performances by many scholars and product development practitioners.
As can be understood from 5.4, the entries in the nine waste indicators are not mutually
exclusive. For example, defective information causes rework (5.4.5). The reason why the
37
author allowed this redundancy is the existence of strong interdependency among waste in
product development: one occurrence of waste can cause many different types of waste,
possibly forming a vicious circle, and this interdependency differs on a case-by-case basis.
Therefore, reducing one waste indicator may make the set of waste indicators an
insufficient one. Thus, the author maintained the nine (plus one described in 5.3.2) waste
indicators at this point; the waste indicators are prioritized in the case studies discussed in
chapter 10.
38
Table 5.2 Definitions and Examples of Nine Waste Indicators
Waste Indicators
Description
Typical Examples
1. Overproduction of
Different
Information (Duplication)
unintentionally
people/groups
are
-Duplicate creation of information due to
creating
the
unclear division of labor
same information.
2. Waiting of People
-People are forced to wait because of
People are waiting.
delay of upstream tasks.
3. Transportation of
Information is in transportation.
-Paper mail, packages
Information (Preparing and
-Tardy approval process with multiple
forwarding information)
signatures.
4. Over Processing
Engineers create information
-Creating information based on defective
that won't contribute the value
data.
of product.
-Trying
to
design
beyond
target
specifications
5. Motion of People
People have to spend time on
-Manual data conversion
(Information hunting, travel,
non value-adding motions.
-Business trips
Redoing tasks perceived to be
-Correcting/Revising designs that failed
finished for some reason
to pass Reviews.
reviews, documentation, and
meetings)
6. Rework
-Updating completed information due to
requirement changes
7. Re-Invention
Designing
without
similar
things
utilizing
past
-Design similar thing twice because past
designs are not well documented.
experience.
8. Hand-Off
Information is handed off with
-Hand-off of information to downstream
(Hand-off inside of project)
its responsibility between two
designers.
groups/people.
9. Defective Information
Erroneous or incomplete
-Design not feasible
(Coupled to Over Processing
information.
-Information that does not meet the
and Rework)
requirements (final, milestone, etc).
5.3.2 INVENTORY OF INFORMATION
39
Inventory of information is different from the nine waste indicators in that engineers' time
is not wasted while information is inventoried. In spite of this, inventory of information was
also identified as one waste indicator in this research because inventoried information can
lose value, causing rework. Inventory of formation is discussed in detail chapter 8.
5.4 ROOT-CAUSE ANALYSIS DIAGRAM FOR NINE WASTE INDICATORS
The complete root-cause analysis diagram is shown in Appendix II
40
CHAPTER 6: VALUE STREAM MAPPING FOR QUANTITATIVE
ANALYSIS OF PD PROJECTS
6.1 OBJECTIVE
Value stream mapping was originally developed for use in manufacturing environment, and
later its scope was expanded to product development environment as PDVSM (Product
Development Value Stream Mapping). For this historical reason, PDVSM took over various
rules for displaying different types of information flows and activities that had been
developed for detailed analyses of manufacturing processes. Some of these rules in
PDVSM are unnecessary in this research because the main purpose of using value stream
mapping is measuring wasted time. Unnecessary rules are eliminated, and, instead, some
minimum set of rules necessary for measurements are introduced in this chapter based on
the suggestions discussed in 4.2.
41
6.2 VALUE STREAM MAPPING (VSM) FOR DETAILED ANALYSIS
OF PROJECTS
6.2.1 TIME LINE AND GRIDS
This value stream mapping is similar to a cross-functional process chart in that it has
process boxes and arrows that represent flows (figure 6.1). One of the major differences
from a cross-functional process chart is that the horizontal axis of the value stream map is a
time line with weekly gridlines.
-
*
I
I
*
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
S
I
I
I
I
I
I
I
I
I
I
I
I
Figure 6.1 Time Line and Grids
42
- - - ---
- -
-
- - -
-
-
6.2.2 PROCESS BOXES - ALLOCATION AND LENGTH
(1) Process Boxes for the Development of the Same Function
If development of a function can be divided into several different phases, each phase should
be assigned one process box (figure 6.2). As can be seen in this figure, downstream phase
for a function is allocated immediately below its adjacent upstream phase
Figure 6.2 Allocations of Adjacent Phases
(2) Process Boxes for Rework
Process boxes for rework should be allocated on the same line of the original tasks (figure
6.3).
Figure 6.3 Allocation of a Process Box for Rework
43
This rule does not apply to the process boxes for different functions (figure 6.4). Different
tasks can be on the same line if they are not for the same function.
Development of different functions.
Figure 6.4 Allocations of Process Boxes for Different Functions
44
......
.......
(3) Beginnings and Ends of Process Boxes
Beginnings and the ends of the process boxes should be consistent with the time line at the
top of the map (Morgan, 2002). As a result, process boxes' lengths become proportional to
the time spent on them.
Week 1
Week 2
Phase 1 was started on the
first day week 1, and had
been worked on for three
days without any interruption
lasting more than one day
Figure 6.5 Beginnings and Ends Process Boxes- Beginnings and Ends of the Process
Boxes Should Match the Time Line at the Top of the Value Stream Map
45
6.2.3 BOXES - COLOR CODES
(1) Displaying Actual Processes (figure 6.6)
Process boxes for actual processes are painted in blue as long as their length do not exceed
the scheduled periods. On the other hand, in cases in which tasks took longer than
scheduled, the excess time should be shown by painting in pink.
Tasks within scheduled time
Tasks over scheduled time
Surplus of scheduled time
day)
Finished earlier than the
Took more time than
original schedule by one
the original schedule by
day
one day
Figure 6.6 Blue, White, and Pink Boxes
(2) Displaying Original Schedules
There are two ways to show original schedules. One way is allocating white boxes that
show original schedules (figure 6.7). This method is effective for clearly visualizing
schedule slippage from original plans. In this research, this method was applied to the case
study in the project B (see chapter 9). However, in cases in which schedule slippage is
significant, or processes are interrupted frequently, this method makes value stream maps
too complicated.
46
Another usage of white boxes is using them only when tasks are finished earlier than
scheduled; in figure 6.6, a white box is used for showing that phase 1 was finished earlier
before its due date by one day. This method is applied to case studies in projects A and C
(see chapter 9).
T
-
w--
-
s
d ---
d-t-m
---
-
Tasks within scheduled time
Tasks overscheduled time
Liii
Original plan
------------------------------
Func. A P1 (1day)
Finished earlier than the
Took more time than
original schedule by one
the original schedule by
day
one day
Func. A P2 (6 days)
I
Figure 6.7 Using White Boxes for Showing Original Schedule
47
(3) Displaying Review and Testing Processes
Review and testing processes should be shown by using diamonds (figure 6.8).
Review
---------------
Review
Figure 6.8 Displaying Review and Testing Processes
(4) Displaying Rework
Rework should be painted in orange (figure 6.9).
Original Work
Rework
Figure 6.9 Displaying Rework
48
(5) Displaying Over Processing
Usually over processing is submerged in value adding activities, but when the whole output
of a process is considered over processing, its process box should be painted in yellow
(figure 6.10)
Original Work
Rework
Over Processing
The whole work was
abandoned
Function A
Review
Phase 2
Original Work
(Over Processing)
Figure 6.10 Displaying Over Processing
6.2.4 ARROWS - COLOR CODES
(1) Information flow inside the same swim lane
Timeliness of information transfer is one measure of information quality defined by Bauch
(2004). Information flows inside the same swim lane should be shown with gray lines if the
transferred information is used in a timely manner (typically within a day: this criterion is
contingent with various factors such as the project's scheduled period and the market's
mobility). If the information is kept untouched for a specific period such as one day or
more, the information transfer is considered as inventory, and it should be shown with
green lines (figure 6.11).
49
Timely Transfer (used in a day)
Delayed Information Transfer
(Inventory of Information)
One Day or More
Within
One
Day
I
Figure 6.11 Timely Information Transfer and Delayed Information Transfer Information Stored for a Specific Period is Distinguished by Using Green Lines
This rule is also applicable for the information stored because the group or the engineer is
interrupted in the middle of a task (figure. 6.12).
t
Delayed Information Transfer
(Inventory of Information)
--
-
----------------------------
One Day or More
Figure 6.12 Displaying an Interruption
50
(2) Information transfer with Hand-Off (Information Flow across Swim Lanes)
Hand-Offs (information transfer among engineers/ groups) are marked in blue if the
information is handed off immediately (figure 6.13). Typically, transferred information used
in one day satisfies this condition. However, this criterion is contingent on various factors
including as the market's mobility and the scheduled development period. Hand-Off in
which information is kept untouched for one day or more is wasteful and is covered by two
waste indicators, hand-off and information inventory. Hand offs with inventory periods
should be distinguished from the other hand-offs by using red lines (figure 6.13).
-
Timely Hand-Off
a
Delayed Hand-Off
Hand-off with Inventory)
One day or more
In one day
--------------------------------------
Figure 6.13 Different Types of Hand-Offs
51
6.2.5 INTERACTIONS
Bi-directional information exchanges are shown by using bi-directional arrows (figure
6.14)
................ f
---------------- *
Figure 6.14 Displaying Bi-directional Information Exchanges
52
. .......
..
. .......
....
.......
6.2.6 CROSS-FUNCTIONAL TASKS
Cross-functional tasks should be shown in the way described in figure 6.15.
.
. LIF.........
inM...
...
Figure 6.15 Displaying Cross-Functional Tasks
53
6.2.7 INTERRUPTIONS
In most organizations, engineers are required to work on multiple tasks. Many scholars and
product development practitioners have pointed out that this multiple tasking significantly
affects product development projects. In this value stream mapping, all tasks that are not
part of the focused project are treated as interruptions, and shown as in figure 6.16.
Timely Transfer (used in a day)
o
Delayed
Information
Transfer
(Inventory of Information)
Interruption
An ExpeditW Task
f 0*
h Projet
Figure 6.16 Displaying Interruptions
54
6.2.8 TIME RECORDING
Time spent on every task should be put on a value stream map (figure 6.17). The total time
of weekly hours of labor of each functional group should also be put on a value stream map.
These numbers will be used for measuring wasted time (chapters 7 and 8).
Numbers in Blue:
Time Spent on Each Task'
Numbers in Orange:
Time
thb
on
Spent
Focused Project
-
-
--- -
-
-
-
-
-
-
--
-
-
-
-
-
-
-
-
-
-
-
I --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
--
-
-
-
-
-
-
-
26
I
--
-
-
-
-
-
-
--
40
-
-
-
-
-
-
--
-
-
-
-
-
-
-
--
-
-
-
-
-
-
--
-
1242
40
40
Figure 6.17 Displaying Spent Time
55
-
-
-
-
-
-
-
6.2.9 WASTE INDICATORS
Measured wasted time should be put on value stream maps in the way described in figure
6.18.
| Inventory of Information
Assigned ID (i stands for inventory)
Inventory period
1001-5days
One of nine waste indicators
Re-Invention
3h)w-001
Wasted time
Assigned ID
(w stands for waste indicator)
Figure 6.18 Displaying Wasted Time
56
.........
....
.......
CHAPTER 7: HOW TO MEASURE WASTED TIME IDENTIFIED BY
NINE WASTE INIDICATORS USING VALUE STREAM MAPPING
7.1 INTRODUCTION OF THIS CHAPTER
This chapter describes ways for measuring wasted time that is detected by nine waste
indicators defined in 5.3. All the wasted time on waste indicators are measured in units of
engineering time.
7.2 OVERPRODUCTION
When overproduction occurred, engineering time spent on overproduction is regarded as
time wasted on overproduction (figure 7.1).
Wasted time is this period
*
.
*
a
*
.
.
.
m
o
to
a
-
a
r
a
a
a
a
Creating the sam information
Non
Value-Adding
Work
Wasted Engineering Time
Figure 7.1 Measuring Time Spent on Overproduction - A Hatched Process Box Mean
Overproduction
57
-
-
§0
-O -0-=---
-
,
-
-
- -
...
-
.
-..
W
AAk
!!P!!!E E9 ;-
=
-
- -
-
-
-
-.-
.-
-
7.3 WAITING
When an engineer was forced to wait doing nothing, the period for which the engineer had
waited is regarded as time wasted on waiting (figure 7.2). Waiting is rare in today's product
development environment, for engineers usually have several tasks in their cues.
Wasted time is this period
-
0
-
a
a
-
0
-
N
-
-
:1//////////////////////Wasted
Engineering Time (A
engineer is just waiting doing
nothing)
Figure 7.2 Measuring Time Spent on Waiting
58
U
7.4 TRANSPORTATION OF INFORAMTION
Sometimes transportation of information takes up a substantial amount of engineers' time.
Figure 7.3 is an example case in which an engineer needs to provide his/ her CAD data to a
supplier. He/ she may need to spend his/ her time on data conversion processes, which is
usually not completely automatic. In this case, time the engineer spent on data conversion is
wasted time on transportation.
Value-Adding
Non
Work (re-formatting)
Example: re-formatting of data
Wasted
Time
Wasted time is this period
Engineeri g
To a supplier,
company, etc.
an
Figure 7.3 Measuring Time Spent on Transportation
59
outsourced
.
"4
__HUM
W-
-_
_1
_
-" -
7.5 OVER PROCESSING
Wasted time on over processing can be measured in the way shown in figure 7.4.
Determination of the actual time spent on over processing usually requires intensive
interviews with engineers, for over processing occurs concurrently with other value adding
work.
Value-Adding
Non
Work (discarded)
Wasted
Time
Wasted time is this period
Engineering
Figure 7.4 Measuring Time Spent on Over Processing
60
7.6 MOTION
Figure 7.5 is an example of motion. In this example, engineer spent some time on
reviewing another engineer's work. Time spent on reviewing is considered to be wasted
time.
Wasted time is this period
I
Vasted
ime
Non
Engineer's
Figure 7.5 Measuring Time Spent on Motion
61
Value-Addin g
7.7 REWORK
Figure 7.6 is an example of measuring wasted time on rework. In this example, the original
work was partially reworked. In such a case, wasted time on rework should be the total time
of A and B (figure 7.6). A is time spent on discarded work, and B, time spent on
troubleshooting. C is considered to be value adding activity. A is sometimes difficult to
measure, but C can substitute for A when measuring wasted time. Examples of
measurements of rework is shown in figure 10.20.
Discarded Portion
Original
Value-Adding
Non
Work (discarded)
(C)
(A)
Wasted
Time
(B)
Engineers'
Measured period
Figure 7.6 Measuring Time Spent on Rework
62
J
I-
!!
5
- ---
I -- -
-
I
=-
---
-
-
-
-
-
-
--L4
-
7.8 RE-INVENTION
Figure 7.7 is an example in which two engineers invented the same information. In this
case, time spent on the second invention is regarded as the time wasted on re-invention.
Work that could have eliminated by
recycling the output by another
engineer
Communication that should have
occurred
U
U
U
U
*
U
U
U
U
m
U
U
U
U
-
-
-
U
-
m
-
-
U
-
N
-
U
U
U
U
U
mummumum
Wasted time is this period
Figure 7.7 Measuring Time Spent on Re-Invention
63
E
U
-
U
7.9 HAND-OFF
Sometimes hand-offs takes both the sender's and the receiver's time: the sender may need
to spend his/her time on documentation that could be avoided without hand-off, and the
receiver usually needs to spend his/her time on understanding the sender's work. Figure 7.8
is an example in which both engineers wasted time on hand-off.
Non Value-Adding Work (documentation)
Wasted Engineers' Time
*
UU
U
U
U
Wasted time is these periods
Figure 7.8 Measuring Time Spent on Hand-Off
64
a
a
UM
7.10 DEFECTIVE INFORMATION
Defective information causes waste of time in various forms including rework, time spent
on reviews and testing, and customer support work after launching the product. Figure 7.9
is an example in which defective information caused rework. In this case, wasted time is
the time spent on creating defective information and fixing it. In many cases, time spent on
creating defective information cannot be easily distinguished from other vale-adding
activities. In such cases, measuring time on fixing defective information is sufficient.
Original work
Discarded Portion
Occurrence of
Defective Inf ormation
Time Wasted, but
Discarded Portion
Measured Period
Cannot be Easily
Measured
Figure 7.9 Measuring Time Spent on Defective Information
65
CHAPTER 8: INVENTORY OF INFORMATION AND HOW TO
MEASURE IT USING VALUE STREAM MAPPING
8.1 INTRODUCTION
Goldratt (1997) insists in his book "Critical Chain" on not allocating buffer times except at
the ends of projects. McManus (2004) puts stress on wastefulness of inventory of
information in his "PDVSM Manual," arguing "work in progress" information may become
obsolete while it is stored. Both arguments share the common idea that created information
should not be kept waiting. However, alike in manufacturing environment, inventory
cannot be completely eliminated for two reasons. One is that product development teams
usually do not have enough numbers of engineers to keep all information busy all the time.
The other is the risks and uncertainties existing in product development projects. This is
why even the scheduling methodology suggested by Goldratt requires buffer time allocated
on feeding paths.
Thus, there exist two tradeoffs related to inventory of information. One exists between cost
of having a big team and cost of having obsolete information caused by having a small
team. The other exists between the risk of depleting buffer time, and, again, the risk of
having obsolete information. Depletion of buffer time unsynchoronizes the whole project
schedule, causing subsequent waste.
Because of these trade-offs, there can be no universal solution for determining the right
number of engineers and the right buffer times: product development organizations need to
know how much inventory of information costs in their specific contexts. Without
quantitative data, they cannot optimize buffer allocations in their schedules. For instance, in
an environment in which market is significantly unstable, a huge team that realizes short
development cycle times may be desirable because information created goes bad quickly.
This research tries to shed light on this topic: the deterioration of information inventory and
how to measure it. 8.2 discusses how information goes bad. "Interest rate" of inventory of
information is calculated in the case study of Project A; the result is discussed in chapter 11.
66
8.2 DEFINITIONS OF ROTTEN INFORMATION AND FRESH INFORMATION
Rotten inventory in this thesis is the information inventory that needs to be reworked
partially or completely due to changes occurred inside or out of the project. For example,
information inventory may need to be reworked because a significant market change is
identified. More discussions on causes of rotten information are covered in 8.3.
8.3 HOW INFORMATION GETS ROTTEN
8.3.1 MARKET CHANGE
In some markets, customers' preferences change so quickly that products can be obsolete in
one year. This means that the specifications set at the beginning of projects may become
obsolete before finishing the projects. Even when customers' preference is consistent, a
product loses its value when a competitor releases a product with similar features because
most of the leading customers are unlikely to buy the second product.
8.3.2 REQUIREMENTS CHANGE
Shifting requirements are also causes for rotten information. Work-in-progress information
may become obsolete by changes in requirements: a fighter's specification is unlikely to be
consistent for ten years. Requirements changes may also be caused by internal events such
as boss change.
8.3.3 TECHNICAL DIFFICULTIES
Shenhar et al. (2003) argues that overlapping among tasks should be less when technical
risk/ uncertainty levels are relatively high. This implies that concurrent engineering's
applicability is contingent on the risk/ uncertainty levels. In concurrent engineering,
downstream tasks are sometimes started with tentative information from upstream tasks.
Working on tentative information may cause rework because the tentative information may
turn out to be defective for various reasons like technical difficulties. In such a case, some
portion of the original work becomes rotten, causing rework (figure 8.1).
67
......
..............
.................
. ...
....
.....
.......
........
..........
Final output (inconsistent with the
pre-released information because
Upstream Work
of technical problems)
Tentative
T- i Replac ment
- -
output
Original
rk
Rotten Portion
(Engineers'
time wasted)
Rework
-
Figure 8.1 Rotten Information Due to Technical Risk
68
CHAPTER 9: OVERVIEW OF THE RESEARCH INVESTIGATIONS
9.1 RESEARCH QUESTIONS
The lean tools and processes are developed through readings and preliminary case studies.
However, it was still uncertain that the tools and processes are applicable for measurements
in industrial product development projects. Specifically, the following questions were
raised.
(1) NINE WASTE INDICATORS
" Are they sufficient to address all the waste in product development processes?
" Are all the waste indicators equally prevalent, or some are more important than
the others?
(2) INVENTORY OF INFORMATION
" To what extent inventory of information is prevalent in industrial product
development processes?
" How quickly inventoried information gets rotten?
" How much labor does it take to refresh rotten information?
(3) THE VALUE STREAM MAPPING FOR QUANTITATIVE MEASUREMENT
*
Can the value stream mapping be applicable for measuring wasted time on every
waste indicator defined in this research?
(4) THE ROOT-CAUSE ANALYSIS DIAGRAM
*
Does the root-cause analysis diagram contain all the causes for wasteful product
development processes?
(5) OVERALL
*
Can the lean tools and processes described above deliver to product development
organizations information that leads to continuous improvement of their
value-creating processes?
69
To answer these questions, the next step is determined to test the tools and processes in
several product development projects.
9.2 ABOUT THE COMPANIES AND PROJECTS
9.2.1 OVERVIEW OF THE THREE PROJECTS
Table 9.1 briefly introduces the three projects investigated in this research. The product
being developed in Project B is the replacement of the one developed in Project A.
Table 9.1 Description of the Three Investigated Projects
Project A
Company
Project B
Company X (Hdqrs: USA)
Investigated
Development Site
Focused Team
Team's Deliverable
Project C
Company Y
(Hdqrs: Japan)
Japan
6 Engineers + Managers
5 Engineers +
Mngers
Managers
Embedded Software for a High-Tech Machine
Total Number of
Involved Engineers
(Partially or Fully)
100+
Status at the Time of
Investigation
Finished
Ongoing
Ongoing
Investigated Period
50 Weeks
17 Weeks
30 Weeks
Investigation
Investigated
Phase(s)
Invetigaion
Detailed Design
Phase
Phase
(After Setting Basic
(After Setting Basic
Specifications) +
Detailed Design
Specifications)Phase
Needs: Unstable
Market Size: Unstable
70
Needs: Stable
Market Size:
Unstable
9.2.2 DIFFICULTIES IN THE PROJECTS
Although the three projects are similar in that they are all embedded software development
projects, they all had their own difficulties.
Project A
Design Issues
* Major architecture design change caused by their decision to integrate several
components of the existing model to a single component.
" Higher complexity incurred due to this integration.
" In spite of more constraints caused by the integrated design, higher performance was
required due to technological development in the market at the time of the beginning of
the project.
Project Management Issues
" Offshore outsourcing.
" Resource contention: most engineers are shared by some other projects, causing
multiple-tasking. In addition, the interruptions by them were not always predictable,
leading to unsynchronization of processes.
Project B
Design Issue
0 Maintain compatibility with the previous model.
Project Management Issue
0 Scheduled to be completed in half the time spent on Project A.
Project C
Design Issue
* Realize high compatibility with the other manufacturer's machine.
" Basically no communication channel with users - their needs are communicated via the
customer.
71
9.3 INVESTIGATION SCHEDULE
9.3.1 OVERVIEW OF INVESTIGATION SCHEDULE
Companies X and Y were visited three times and twice respectively. Phone calls and emails
had been exchanged between and after the visits. Company X's investigation lasted for
three months, and Company Y's, two months. Detailed schedule for the investigation of
Company X is described in the following sections. The investigation of Company y
followed similar processes, although I could make it more efficient by applying what I had
learned through the investigation of Company X.
9.3.2 DETAILED SCHEDULE FOR COMPANY X
Preparation
A telephone conference was held with two project managers and one engineer; all of them
were active members of projects A and B. Basic information about both projects (project
periods, the team's roles, number of involved engineers) were informed, and the scope of
the investigation was discussed. Both parties agreed to start the investigation at the end of
the conference.
The First Visit
Activities
The first visit to company A lasted five days. On the first day, basic information about the
two projects (including organizational structure and its changes, detailed processes, the
products, and the market) was explained by the project managers and an engineer. The
second and third days were spent on drawing the first version of Project A's value stream
map. Last two days were spared for interviews with one of the project managers and all the
available engineers engaged in Project(s) A and/or B. Each interview took 30 to 60 minutes.
Common interview questions included the following:
* "What do you think was the difference between the two projects?" "Why do you think
so?"
* "What kind of difficulties had you encountered through Project A?
These questions worked as effective catalysts.
Although most meetings were held in the company's conference rooms, I was allowed to
occupy a desk located close to the development team. This helped me to develop a better
72
understanding about how they work, how information is exchanged, and even each
engineer's personality.
Obtained Data Other than from Interviews
Project A:
*
*
MS-Project files with the scheduled and actual processes.
Each engineer's weekly reports sent to the project managers. The report includes
information about time spent on each task, updated information about the problems and
difficulties the engineers encountered, and their updated plans for the month.
Project B:
* The MS-Project file that included both the scheduled and actual processes.
What I learned
Value stream maps for the finished portions of projects should be completed if possible, for
drawing them takes long time. In order to do to do this, both actual and planned schedules
should be obtained well before a visit. For this reason, before I visit Company Y, I obtained
as much information as possible, leading to more effective and efficient information
exchanges then.
Between the First and the Second Visits
Weekly Updates from the Project Manager
Project B's weekly reports were sent from the project manager to me through the internet
every week. The reports were basically intended to report to the other project managers,
and they contained information obtained through peer-to-peer interviews with each
engineer, the actual time spent on Project B. Updated MS-Project files were attached to the
reports. Telephone conferences with the project manager were held for thirty minutes on
average almost every week; most of the time was spent on asking questions about the
recent weekly reports.
Other Information Exchanges
Additional information was obtained by exchanging emails and phone calls with engineers.
73
Drawing Value Stream Maps
Project A's value stream map was made based on the schedule information in the
MS-Project file. Project B's value stream map was updated after each telephone conference.
The Second Visit
Intensive interviews with the project manager and all the available engineers were
performed through this two-day visit. Tentative versions of the value stream maps were
used for asking questions. Project A's value stream map at that time had information about
schedule slips, and interviews were focused on repeatedly asking the reasons for the slips
until root causes were identified as is suggested by Ohno (1978). Project B's value stream
map, having more detailed information than Project A's by then, was used for asking
reasons for identified wastes and information flows that had not been identified in the value
stream map.
Between the Second and the third Visits
Almost same activities and information exchanges were performed as the first interval.
Several reports on Project A's design/code reviews were obtained. Project A's value stream
map was improved reflecting the recent interview results and the information in each
engineer's weekly reports.
The Third Visit
With more detailed value stream maps, intensive interviews with engineers were performed.
A presentation showing tentative results was held in front of two project managers and
several engineers, followed by extensive discussions.
After The Third Visit
Value stream maps were updated by reflecting the recent interview results. Root-cause
analyses using the root-cause analysis diagram were performed based on all the information
obtained by then and additional emails and phone calls. Wasted time on each identified
waste was measured using the methodology explained in chapter 7.
74
CHAPTER 10: RESULTS OF RESEARCH INVESTIGATIONS
ANALYSES ON NINE WASTE INDICATORS
1:
10.1 OVERVIEW OF THIS CHAPTER
10.2 looks into the wasted time captured by the nine waste indicators. Some waste
indicators were more significant than the others. 10.3 analyzes the result by looking into the
causes for the wasted time with the root-cause analysis diagram. 10.4 summarizes this
chapter.
10.2. OVERALL RESULTS
10.2.1 NUMBER OF OCCURENCES
Figure 10.1 shows the occurrences of waste indicators per 50 engineering weeks in the
three projects. Motion was the most frequent in all the projects. Especially, its occurrences
were outstanding in Project C. The occurrences of over production, waiting, and rework
were fewer than the others. Project B had fewer occurrences of rework and defective
information. One of the reasons for this is that most of the tracked period of Project B was
on the investigation phase, on which some need for rework may be undiscovered, and the
rework not yet done.
75
Occurences of Waste Indicators per 50 Eng. Weeks
500
465
450
w
400
350
Co30
3 00
U Project A
25
0
0 Project B
0 Project C
0
Z
0
143
2 150
85
100
Z
I
10
50
3 2 0
4 2
10
-
0
37 35
44
1
0
0
C
0
C
0
2
0
C
0
0
I6
C
0
0
W
d
0
Waste Idicators
Figure 10.1 Normalized Occurrences of Waste Indicators per 50 Engineering Weeks in
Projects A, B, and C
76
10.2.2 AVERAGE WASTED TIME PER ONE OCCURENCE
Figure 10.2 shows the average wasted time on each waste indicator in the three projects.
The overall average wasted time per one occurrence of waste indicator in Projects A, B, and
C were 17, 3, and 8 engineering hours respectively. Overproduction took 23 hours in
Project A on average. Waiting, along with motion and hand-off, had less average wasted
time than the others. Over processing, rework, and defective information took 17 hours or
more on average, except in Project B, which was on its investigation phase during my
survey period.
Wasted Times per Each Occurrence of a Waste Indicator
25 F 23
24
23
22
20
20
20
20
17
0
17
15
15
E
U Project A
C
0 Project B 1
Z;
0 Project C
10
7
8
7
6
6
6
5
4-4---
5
3
0
3
1
1
00
0
0
CL
0
o
CL
C
(b
W
0
a)
.
6
cc
E
*-C
0
Waste Indicators
Figure 10.2 Wasted Time per Each Occurrence of a Waste Indicator in Projects, A, B,
and C
77
10.2.3 TOTAL WASTED TIME
Figure 10.3 shows the total wasted time on each waste indicator in the three projects. Over
processing, motion, rework, and defective information were the top four waste indicators in
almost all the three projects. This implies that the four waste indicators are more important
than the others. Although one occurrence of overproduction wasted 23 hours on average in
Project A, the total wasted time on it was trivial compared to the top four waste indicators.
Waiting was also trivial, implying engineers always have some tasks in their cues.
Project A's wasted time on over production was outstanding among the three projects,
indicating that 1,438 engineering hours were wasted for some reasons, including changes
and errors. Project A also wasted time on rework more than the other two projects. Project
B's wasted time was much less than the others in transportation, motion, rework, and
defective information. This result will be analyzed in detail in 10.3.
78
Wasted Times per 50 Eng. Weeks and Waste Indicators
2500
2357
CD
2000
Cb
0
1438
1500
290
M ProjectA
1382
0 ProjectB
IOUU)
978
1000
713
-
871
760343
243
N
500
0
94 145
192
135
70 18 0
17 12 0
220
0
20
I0t
0
C
0
C
C
0
C
0
0)
2
-
0
0
C
0
C
0
0~
V
C
CU
I
C
Waste Indicators
Figure 10.3 Normalized Total Wasted Time per 50 Engineering Weeks and Waste Indicators
79
A ProjectC
10.2.4 TEMPORAL CHANGES IN WASTE INDICATOR DISTRIBUTIONS
Figures 10.4-10.6 show temporal changes in waste indicator distributions in Projects A-C
respectively. In Project A, the total wasted time fluctuated over time. This fluctuation
implies the software team's activities, which are the downstream tasks of the hardware
team's activities, had largely been affected by intermittent hardware releases, for Project A
involved major changes in both hardware and software. In contrast, Project C, which
involved no major hardware change, had much less fluctuation than Project A. Wasted time
on rework increased as time spent on the project increases in all three projects.
Temporal Changes in Waste
Indicator Distribution (Project A)
1000
900
800
700
-
0
C
o Defective Information
0 Hand-Offs
3 Re-Invention
a] Rework
o Motion
E Over processing
E3 Transportation
* Waiting
* Overproduction
'--NV--'
600
ZZ
0)
E 500
-
--
-
-N
400
-:1,
1
300
-
!
A.. -V
-s
-a-l
200
100
0
-5
6-10
11-15
16-20
21-25
26-30
Eng. Week
31-35
36-40
41-45
46-50
Figure 10.4 Temporal Changes in Waste Indicator Distribution in Project A
80
Temporal Changes in Waste indicator Distribution
(Project B)
1000
900
800
0 Defective information
700
NHand-Offs
0
E3 Re-Invention
1 Rework
E Motion
2 Over processing
0 Transportation
E Waiting
* Overproduction
600
4k
500
-
400
300
200
100
0
1-5
11-15
6-10
Eng. Week
Figure 10.5 Temporal Changes in Waste Indicator Distribution in Project B
81
Temporal Changes in Waste Indicator Distribution (Project C)
1000
F
900
800 1
0 Defective
Information
* Hand-Offs
* Re-Invention
[1 Rework
700
aZ
:3
600
E
-
500
El
400
E Over processing
0 Transportation
E Waiting
0 Overproduction
. .
. . . . . . . . . . . . . . . .....
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . ... .. .. .. .
. . . . . .
. . . . . . . . . . . . . . .
. . .
.. .. ... ... .. .. ... ... . . . .
. . .. . . . ..
. . . . . .. . . .
. . . . .. . . . .. .
. ..
. .. . . .
300
V
Motion
.. .. . . .. .
200
100
0
-
1-5
-
- -
-
-
-
- -
6-10
-
-
-
.
-
11-15
16-20
Eng. Week
. .
.
.
.
.
21-25
. .
.
26-30
Figure 10.6 Temporal Changes in Waste Indicator Distribution in Project C
82
10.2.5 DISTRIBUTION OF WASTE INDICATORS AMONG ENGINEERS
Figures 10.7, 10.8, and 10.9 show the distributions of waste indicators of each engineer in
the three projects. As can be understood from these figures, the distributions differ
significantly among engineers. Tables 10.1, 10.2, and 10.3 briefly introduce the engineers'
profiles. These results illustrate the following:
Waste indicator distribution is contingent on each engineer's qualification level, each
engineer's role, and how information flows.
An example related to engineer's qualification is engineer T's ratio of rework to defective
information. This ratio is significantly bigger than that of most of the others. This implies
that it is not often for T that he makes errors by himself. This tendency is consistent with
his high experience level and his character as a perfectionist (see table 10.1).
Looking into the distributions of U (in Project A) and NF (in Project C) reveals that the
waste indicator distribution is also affected by each engineer's role. U in Project A and
Engineer NF in Project C had similar waste indicator distributions: they are the only
engineers who had wasted his/her time in the following order.
1. Motion, 2. Rework, 3. Defective information
As can be understood in tables 10.1 and 10.3, they share the same role: they are both
responsible for engineering issues of other engineers while working on their own design
tasks. In Project B, U's waste distribution changes significantly: he/she wasted his/her time
on hand-off most. This is mainly because his/her role in Project B was project manager who
provide with the engineers tasks and necessary information including specifications.
Engineer H's waste indicator distribution in Project A is a distinct proof that the distribution
is affected by how information flows. H wasted his time on over processing most. This was
due to his working on tentative information, which was caused by late information releases
from the hardware team.
83
Waste Indicator Distributions by Engineer (Project A)
100%_
A-3017
80%*
andOf
o Defective
80%
(D
0)
Information
* Hand-Off
* Re-Invention
E~
* Trasportatio
Rework
40%
60%
63 Motion
10
a.)
(I
0 Over Processing
40%'
E3 Transportation
o Waiting
0 Overproduction
".0
20%
/c
I
0%
F
M
7
f"77.
T
Y
H
U
Engineer
Figure 10.7 Waste Indicator Distributions by Engineer (Project A)
Table 10.1 Each Engineer's Profile
Engineer
F
Young engineer. First experience in a major software development project.
M
Experienced engineer.
T
Experienced engineer. Seeks for perfection in his tasks.
Y
Young engineer with high motivation.
H
Experienced engineer.
U
Not the project manager, but leads the team in technically like a chief
engineer.
84
Waste Indicator Distributions by Engineer (Project B)
100%_
0 Defective Information
E Hand-Off
80%
7 Re-Invention
18 Rework
CM
l Motion
60%
% Over Processing
40%
El Transportation
O Waiting
30%
U Overproduction
20%
10%
0%
U
Y
F
T
N
J
Engineer
Figure 10.8 Waste Indicator Distributions by Engineer (Project B)
Table 10.2 Each Engineer's Profile (Project B)
Engineer
U
Working project manager: not only manage the team, but acts like the
team's buffer. (see also table 10.1)
Y
(see table 10.1)
T
(see table 10.1)
F
(see table 10.1)
N
Experienced engineer.
J
Temporary engineer. Limited experience in software engineering.
85
Waste
100%
-..
~~ ~
.. ..
Indicator Distributions by Engineer (Project C)
. .
. ..
.
. . . .~
-..
-.
.
. .-.
80%
o Defective Information
* Hand-Off
* Re-invention
* Rework
* Motion
60%
C
a-
E Over Processing
KZ.
NF.
H..G..
40%
0 Transportation
* Waiting
* Overproduction
20%
0%'
Engineer
Figure 10.9 Waste Indicator Distributions by Engineer (Project C)
Table 10.3 Each Engineer's Profile (Project C)
Engineer
KZ
Young engineer with limited experience. Unfamiliar with the company's
coding rules/ design philosophy.
NF
Not the project manager, but leads the team in technically like a chief
engineer.
HG
Experienced engineer. No experience in the function assigned in Project C.
Experienced engineer. No experience in the function assigned in Project C.
IH
Young engineer.
HS
86
10.3 DETAILED ANALYSIS ON EACH WASTE INDICATOR
10.3.1 OVERVIEW
The five waste indicators that were not more significant than the others (see figure 10.3),
overproduction, waiting, transportation, re-invention, and hand-off, are briefly reviewed in
this section. The top four waste indicators, over processing, motion, rework, and defective
information are analyzed in detail using the root-cause analysis diagram.
10.3.2 OVERPRODUCTION - WASTED ENGINEERING HOURS BY CAUSES
Figure 10.10 shows the relationship between wasted time on overproduction and the
corresponding causes. Overproduction was identified in Projects A and B. Unclear division
of labor was the significant cause in Project A. On the other hand, the only cause identified
in Project B was under qualification, meaning an engineer's qualification was not enough
for the assigned task.
Making use of the architecture of previous model
The engineer added source codes without fully understanding the legacy source codes,
causing redundancy source codes.
Premature architecture design
This made the architecture too complex, causing redundancy in design.
Under qualification
Inexperienced engineers tend to make redundant source codes.
Unclear division of labor
Two engineers took care of the same task unintentionally.
87
Wasted Times on Overproduction and Causes
40
36
35
J
30
24
C
25
LO
0
E
-
U Project A
20
0 Project B
4-1W
MProject C
15
10
10
(n
5
0
0
0
C
(D
0
>
f 5
cc,0)~
E
0
C
0)
Cc
0
(D
A
0
<)
C
0
Causes
Figure 10.10 Normalized Waste Time on Over Production per 50 Engineering Weeks
and the Corresponding Causes
88
10.3.3 WAITING - WASTED ENGINEERING HOURS BY CAUSES
Figure 10.11 shows the relationship between wasted time on waiting and the corresponding
causes. Waiting was identified Projects A and B. Insufficient maintenance of development
environment and limited tools/ prototypes/ hardware were the causes respectively. This
result implies that engineers are forced to wait only in the unexpected situations in which
they encounter some hardware problems; in other situations, they switched their tasks. For
example, when some information was necessary to process a task, the engineers started
working on another one instead of waiting for the information.
Wasted Time on Waiting and Causes
(D
18
16
C
LO
0
E
17
14
12
10
8
M Project A
0 Project B
M Project C
6
4
2
0
(D
C
Ca
CL
E
C
~0
0
0
U)
C
U)
0
0
C
Causes
Figure 10.11 Normalized Waste Time on Waiting per 50 Engineering Weeks and The
Corresponding Causes
89
10.3.4 TRANSPORTATION - WASTED ENGINEERING HOURS BY CAUSES
Figure 10.12 shows the relationship between wasted time on transportation and the
corresponding causes. Although transportation was identified in all the three projects, their
distributions of causes were different from each other: only spatial/structural barrier was
shared by multiple projects. In Project A, Changes in design methodology and changes in
documenting / database format/ guidelines were the two significant causes. Both causes
re-formatting information (figure 10.13).
Changes in design methodology
Design methodology change was decided in favor of higher performance, causing
reformatting source codes.
Wasted Time onTransportation and Causes
90
80
70
68
62
60
53
51
0
50
U Project A
40
0 Project B
a Project C
E 30
U)
cc
20
9
10
0 0
0
3
0
0
0
01
0.
0) -a
CQ0
0
0
C
0
-0CV
-o
00
ca
16
*0 0
(00
CU~
0
ca
0
Causes
Figure 10.12 Normalized Waste Time on Transportation per 50 Engineering Weeks
and the Corresponding Causes
90
There' s No Perfect Suite
Product
itself
Manual Handling 4_Use of Paper
of Information
Documents
Adoptin
Fo
Impedfed
Compatibility Of
Different
PlatfOrmsisoftware
ifrn
Software Copan
Difference from
Suppliers'
Software Indstry' s
odto
yai
Legacy from Past
Developments
Outsoucing
Fltom
Transportation
of Infornatlon
Changes
in Documenting
JX/Database Formal
Guidelines
reformatting
Changes in Design
Methodology
T C
Structure
ScatteringLoais
Spatal/trucura
BarierComplex
Hierarchy
Structure of Organization
Funcb"nal
rga
nio
Figure 10.13 Part of the Root-Cause Analysis Diagram of Transportation of
Information
91
10.3.5 OVER PROCESSING
(1)Wasted Engineering Hours by Causes
Figure 10.14 shows the relationship between wasted time on over processing and the
corresponding causes. Over processing was more significant in Project A than in the other
two. (i) "Undiscovered errors in outputs from upstream", (ii) "Upstream changes/ poor
concept design/ marketing information" were the most significant causes in Project A. (iii)
"Prototype version confusion" was the most significant one in Project B.
(2) Examples of Root-Cause Analysis
The root cause analysis of the causes (i), (ii) and (iii) are quoted from the root cause
analysis diagram discussed in chapter 5 (see figure 10.14).
(i) Undiscovered errors in outputs from upstream.
As can be understood from figure 10.14, the typical root causes for this cause are the
following:
-
Defective information
-
Upstream task's dependency on downstream tasks for verification
Existence of risks / uncertainties
-
Limited resources (3) - Limited capacity of organization
(ii) Upstream changes/ poor concept design/ marketing information
As can be understood from figure 10.15, the typical root causes for this cause are the
following:
-
PD's nature (3) - Identifying all interfaces in advance is impossible
-
PD's nature (2) - Iteration cannot be eliminated
-
Poor marketing information
-
Poor concept design
-
Poor architecture design
(iii) Prototype version confusion
As can be understood from figure 10.14, the typical root causes for this cause are the
following:
- Poor work-in-process version management
-
Scattered locations
-
Complex organizational structure
92
-
Outsourcing
-
Functional organization
-
Complex hierarchy structure of organization
93
0
a)
C
Ci)
CD
CA
Poorly manufactured
prototype
Design technique/
philosophy not consistent
with the organization's
Schedule pressure
Unclear task
Strategically processing
multiple solutions
Limited
tools/prototypes/hardware
Defective information
Prototype version
confusion
Insufficient pervasion of
goal information
Insufficient /no
communication
creating a workaround
solution
Upstream changes / poor
concept design /marketing
information
Undiscovered errors in
outputs from upstream
C)
C)
C)
C)
CD
C)
w
C)
CD
C)
C:)
C)
C))
C)
C)
C)
C)
0
CD
C)
C>
CA)
0
~CD
*0
i-u
~2
11
1
0O
a
C)
CD
Cn
.C
CD
CD
CD
-.-
CD
C)
0)
-4
C)
C)
Wasted Time [ Hour / 50 Eng. Weeks]
Co
o)
OD
C)
C)
CA
CA
(D
0
CD
0
(A
CL
111111111111111
C)
C)
(0
PD's Nature(2)
Iteration cannot be
eliminated
Interface
Optimization
Process
Redesign
PD's Nature(3)
Identifying All Interfaces
In Advance is bripossible
Upstream
Poor Marketing
Changes
Poor Information Quality
from Upstream Phases
Concept
Design
Premature
Premature ArchZItetr
Design
Poorly
manufactured
Prototype
Late /Lack
Verificationy-Process
Undiscovered
Working on
Unreliable/
Defective Info.
rification by
Existence of
Uncertainties/Risks
Process
V esting,etc.)
Outputs fromr
-
Pe rformed by
D rwnstream
Tasks
Irvdependent
Errors in
4.Over4.Ove
Processing
Upstream Task's
Dependency on
Downstream Tasks
for Verification(E.G.
Manufacturability)
enfiction
-
(T
Upstreaml
19. Defective
Information
'erified by
External
Or ganization/
People
Limited
Resources(3)
Limited Capability of
Organization
Limited
Overlapping
Schedule
Resources(1)
System Over
Utilization
(Unrealistic
Schedule)
Concurrent Engineering(2)
Information Pulled Before
Validation and/or Optimization
of Design Parameter Sets
-- Hghl CometiiveMarket
Too Much Concurrency
(Complex product or LowTRL)
Prototype
Version
Confusion
Work-in-Process Version
Management
lnsufficient/ No
Communication
Scattered
Locations
Spatial
Barrier
Complex
Organizational
Structure
Outsourcing
- -
Functional Organization
Complex Hierarchy
Structure of Organization
Figure 10.15 Part of the Root-Cause Analysis Diagram of Over Processing
95
(3) Discussion
The most significant cause of over processing in Project A, "(i) Undiscovered errors in
outputs from upstream," is common in many embedded software development projects in
which both hardware and software are developed concurrently. The first two root causes,
"Defective information" and "Upstream task's dependency on downstream tasks for
verification" reveals the wasteful relationship between the hardware and the software team,
in which defective information flows down to the software team (figure 10.16). Because of
this pattern, the software team needed to waste time on defective information for which
they were not responsible. Creating defective information itself is wasteful. Passing the
defective information to downstream is also wasteful. If there had been an effective
verification processes before handing of information to the downstream team, both teams
could have reduced wasted time: the software team can reduce time on over processing, and
the hardware team can get feedback quickly. It is generally difficult to test prototype
hardware without a complete version of embedded software, but finding ways to check
errors effectively before handing off hardware prototype can reduce waste, along with
efforts to improve prototypes' quality (this is more essential), can some portion of the
wasted time of 911 hours / 50 months (figure 10.13).
The third root cause, "Existence of risks / uncertainties" cannot be controlled. However,
wasted time on over processing can be reduced by identifying risks/ uncertainties earlier by
introducing front-loaded processes including set-based concurrent engineering, or spiral
processes.
The fourth root cause, "Limited capacity of organization," may be controlled. However, it
is usually difficult because bringing up embedded software engineers takes longer time than
general software engineers because embedded software engineers need to have expertise
for specific hardware.
96
H ardware Team
verification
(ii) The
process between two
teams is not effective.
(i) Defective information
is created here.
*
Embedded Software
Team
(Wasted 911 hours)
Figure 10.16 Wasteful Information Flow without Effective Verification Proce sses
The identified root causes for the second significant cause, "(ii) Upstream changes/ poor
concept design/ marketing information," suggests that Project A's concept development
phase might have been premature. Because the project was processed without mature or
good information, the team happened to spend 195 hours /week on over processing.
However, some portion of this wasted time is caused by deterioration of information, which
is discussed in the next chapter.
97
10.3.6 MOTION
(1) Wasted Engineering Hours by Causes
Figure 10.17 shows the relationship between wasted time on motion and the corresponding
causes. The top three causes for motion were (i) "Documenting", (ii) "Testing/QC" (iii)
"Meeting." In these investigations, testing/QC included only review and testing tasks
performed by other engineers. This was because self-testing activities were not clearly
distinguishable from fixing errors.
Documenting and testing/QC were the most significant causes in Projects A and C, while
they were not significant in Project B.
Wasted Time on Motion and Causes
400 - 381
350
298
300
271
U2502221
0 Project A1
LO
-
200
O Project B
0 Project C
aE 150
94
100
40
50
36
2000o3
0
00
.2
0
a
E
.
0)
.C
0
D
211
C:
M~0.
(D)
Causes
Figure 10.17 Normalized Waste Time on Motion per 50 Engineering Weeks and The
Corresponding Causes
98
(2) Examples of Root-Cause Analysis
The root cause analysis of the causes (i), (ii) and (iii) are quoted from the root cause
analysis diagram discussed in chapter 5 (see figure 10.18).
(i) Documenting
As can be understood from figure 10.18, the typical root causes for this cause are the
following:
- Required activity
- Transportation
While documenting wastes the ongoing project's time, it may save time later in future
projects: without easy-to-access documentation, re-invention waste may occur in the future.
(ii) Testing/ QC
As can be understood from figure 10.18, the typical root causes for this cause are the
following:
-Defective information.
-Outsourcing
Testing activities are classified as waste because the better development processes are, the
less time for testing is needed. This means that a development process with long testing
time is not always a process that guarantees high quality products. Rather, it may be a poor
process whose work-in-process information's quality is poor because defective information
causes long time for testing that might have been unnecessary without defective
information.
(iii) Meeting
Not all meetings are wasteful: because well-organized meetings lead to high-quality
information transfer (Graebsch, 2005). On the other hand, meetings for unilateral
information transfer and with unnecessary attendants are wasteful, causing other wastes by
taking engineers' time.
(3) Discussion
Considering the three major causes for motion identified, measuring time spent on motion
is not a good way for waste reduction. Documenting can be considered as investment for
the future. Spending long time on testing is waste, but one of the two causes of it is
defective information, which is one of the waste indicators. In fact, in Project C, design
reviews sometimes worked as a training process. For example, many design reviews can be
99
seen figure 10.19. The project spent long time on the reviews, which lasted 1.5h-2h each,
but the reviews helped KZ learn the coding guidelines and the design philosophy of the
company. Using design reviews as an opportunity for training may not always be the best
way of training, but it can also be regarded as investment for the future. Deciding whether a
meeting is wasteful or not requires a careful analysis.
Defective
Information
Outsourcing
Stop-and-Go
Tasks
Meeting
Desire to Save
Just for
nformation Sharing
--
Information Releaser s
Time
5. Motion
Intensive
Interaction' sHelpfulness
for Creating
Ideas/Problem
Solving/DR
Narrow Bandwidth of
Meeting for Value
Creation/Problem
Solving/Design Review
-Meetings
t
Existing
Network(Resuting inLow
Limited Capabili ty of
Tele-Conferen ce
ResolutionLate
Response)
Business Trip
Premature
Complex Organizational
Structure
SpatialBarri er
Spend Time on Learning
How to Use Support
Equipments
-- -
Outsourcing
Complexity of Support
Equipments
Equipments
oumng
-Supporting
Scattering locations
--
Spend Time on Complex
Operation of support
I
IT Tecnology
Required Activity
*ting+--
--
--
3.Transportation
Outsourcees
Figure 10.18 Part of the Root-Cause Analysis Diagram of Motion
100
Wk9
Wk8
Wk7
Rework
V1040
10/31
10/24
Wk10
11/7
11;
Mvotion 1zhI WM I
1:9
Tr ed to clarify precie
--
i n n
(Gh
Deign
review
D
log
r
AL
w022. v23.
w024 Design
review
fi otion f2hli
E'rraceo
software)
Reviodl (24h)w O
Sefe
I
Motion (2h) w0.r20
Docum nting
:
(2A) v1.1
tive Info.
Motion
D
10
25
101022
DR2
DR2
Test
e
(2f)v039
nMotion
13 28
13 +27
On PR
+
w4
Iterati n
(optim zation
118
7 11
2
.
Rew rk I6h)
Documen ng
2e,
Motion 12hl w042
Design review
(21h'3) v034. 035, v'36
Documenting
enting
otion I1.5hl
It
Design revie
Under qu alificatio:
klotion f2h'3)
wJ25. vv)26.
woO2 7
4 1w037
Docur
Design ReviAev
v019
sign revi4 Vol 9
lotion
Motion 1 .5h*3j w031. w032, w033
Motion 12h,31
Derectiv.
proce s)
C14
008-3day
Defect4e Info. J8hI
Under 4ualification
3
Rework
4-1
Rework :16
vnO29
Corkshops
p4hF
Rewo*
DR
Cause
21
AL
-
w,02
F; 2 nji 5h1
hI
nI' v
DR
LA 6;
-3h
w132
Motionl2hl
w134
w135
Design review
Design review I
Motionhi
Ds139
Design r
klotihp1[.5
nlo1hi U o i3
w140
ign review
w141
.y
v 44
3
Design revieav Design review
Motionl2h)
hl
w1
VA 46
Design review
Figure 10.19 Example of a Process with Frequent Design Reviews - Engineer KZ's design Process in Project C
101
10.3.7 REWORK
(1) Rework in VSM
As can be seen in figure 10.20, rework is conspicuous in value stream maps. It can be easily
understand how time is spent on rework by taking a glance of a value stream map; in
Projects A and C, some engineers spent more than half of their time on rework.
4
7
44.5
13-5
10
38.51
35.5
49.5
--
13
26
10
48.5
4C
30
5
24
26
4
Wy
22
5
935
(2h)
(1211
~
Rework (orange boxes)
1
6
8/30
39.5
7/7103
7l14bO3
45
7/21103
28
7
7)28
35.
si/4/o
45
911
4
gri
51
82
'49/
9/9
Figure 10.20 An Example of Rework in Value Stream Map (Project A, Engineer T)
(2) Wasted Engineering Hours by Causes
Figure 10.21 shows the relationship between wasted time on rework and the corresponding
causes. Rework was significant waste identified in Projects A and C. (i) Troubleshooting
and (ii) Defective information were the most significant reasons for wasted time on rework
in Projects A and C respectively.
102
Wasted Time on Rework and Causes
1400
1237
1200
1000
861
C
wU
0
0 Project A
800
O Project B
0
E
4U
0 Project C
600
400
18
200
11
6 271
'
0
0)
0
.C')
4)
25
C
4)
.2
C.,
4)
4)
0
C
oo
0
76
31
'1 25
0 M
a
0
C')
CM
C
C
.C
E
CU
C
0
Cu
,
0 0
4
0
7
C
0)
C
0
I--
Co
C
0
.0
Cu
0
(n)
E
E
4)
C.)
0
0.
4)
0
0L
0
D.
0180
rTn1
1
_C
0 9 33
0
0
0
C.
CL
0 35
C
*0
20
0 0 10
0 0 40
C
0
9
E
C
Cu
4)
I
4)
0
Causes
Figure 10.21 Normalized Waste Time on Rework per 50 Engineering Weeks and The Corresponding Causes
103
(3) Examples of Root-Cause Analysis
The root cause analysis of the causes (i) and (ii) are quoted from the root cause analysis
diagram discussed in chapter 5 (see figure 10.22). Troubleshooting is caused by defective
information, but, in this investigation, when a engineer had spent his/her time on
troubleshooting, the wasted time was classified not as the rework time caused by defective
information, but troubleshooting. On the other hand, when a engineer had spent his/time on
fixing defective information, the wasted time was classified as rework time caused by
defective information.
(4) Discussion
Figure 10.23 explains why 861 hours are spent on troubleshooting in Project A. As can be
understood from this figure, the embedded software team needed to take care of the errors
both in hardware and software. This made troubleshooting processes complicated.
Furthermore, the software engineers had limited knowledge in the prototype hardware.
Especially the inexperienced engineers (F and Y) spent long time on identifying where bugs
are in. The quality of their work were not as high as those of experienced engineers then
(they showed notable improvement in Project B). And, their troubleshooting processes were
not as effective as those of the experienced engineers. Their lack of confidence, coming
from inexperience, sometimes made them take long time before determining who was
responsible for the bugs. It was sometimes difficult for them, partly because of the Japanese
culture, to point out errors made by hardware engineers who were more experienced. Thus,
engineers wasted 861 hours on troubleshooting.
Part of the huge wasted time on project A is considered to be caused by inexperience of
some engineers, but some portion of it might have overcome by appropriate project
management. The project managers sometimes ignored alarms by the young engineers,
having put priorities on immediate issues: this made rework discovery time longer.
Postponed rework makes time spent on it longer; this is discussed in (5).
Suggestions for reduction of troubleshooting time are the following:
1. Find ways to stop defective information flow across teams.
2. Let engineers work at their best conditions: too much overtime and excessive schedule
pressure cause low-quality outputs.
104
3. Try to retrieve alarming information from engineers: hidden problems are sometimes
troublesome than visible ones. (This seems to be already realized by U in Project B)
On the other hand Project C spent 1,237 hours on rework caused by defective information.
Defective information is discusses in 10.3.9.
105
9. Detective
Information
PD' s Nature(1)
Complete Elimination of
Risks/
Uncertainties is
Impossible
impossibility opeeycerRss
division of labor
clear
IImpossibility oof completely
diiino-ao
Unclear division
of labor
Complex Organizational
Structure
Stru/ture
Unplanned
Iteration
Inability of Prompt
Adjustment of
Division of Labor
Tardy
4-
Outsourcing
nfoation
Transfer
Functional
6. Rework
Organization
Complex Hierarchy
Structure of Organization
Prototype
Version
Confusion
-
FienU/Nl
Creation of Low
Quality
4
Information
ICommienton
Poor
Work-in-Process Version
Management
Scattered
Locations
Spatial
Barrier
Complex
Organizational
Structure
Outsourcrng
Functional
Organization
Complex Hierarchy
Structure of Organization
Schedule
Pressure
t
Schedule
Limited Resources (1)
system Over Utilization
Highly Competitive
Market
Time-Sensitive Product
Way-Off
Schedule
Inadequate Schduling
Technique
Insufficient
rainig
e
UnderPoR
ualificationon
Resources (2)
Qualification
of Designers
Limited
-Limited
Troubleshooting
_L
/Diagnosis
J
Working on Unreliab e/1a
Defective Information
Figure 10.22 Part of the Root-Cause Analysis Diagram of Motion
106
l
9. Detective
Information
Hardware Tean
The verification process
is not effective.
Embedded Softw re'+
Team
brea
g
***
Flow of defective inf arm ation
Embedded Software
Team
(Wasted 861 hours)
Figure 10.23Wasteful Information Flow without Effective Verification Processes
(5) Changes in Rework Time
Figures 10.24 and 10.25 show changes in the average time spent on one occurrence of
rework over time. Projects A and B were put on the same graph. Project A's start week was
shifted by fifteen weeks because the tracked period started after the completion of its
investigation phase, which took about 13-151 weeks in Project B.
The two graphs proved that one occurrence of rework takes longer time near the end of a
project than at the beginning of it, and their increases are exponential. Project A's curve
fluctuated. This is because information came from the upstream team (hardware)
periodically: the software team identified rework after some information releases such as
detailed specifications releases, and prototype releases.
These results imply that problems should be identified as soon as possible. Possible
solutions are the following:
1. Introducing a suitable spiral process with frequent prototyping
2. Introducing a front loaded process such as set-based concurrent engineering
3. Trying to listen to engineers. Watching for hidden problems.
1 Not
all the engineers switched themselves to the second phase at the same time in Project
B.
107
Average Time Spent on One Occurrence of Rework and Week (Projects A and B)
80
70
67
0
60
57
50
a)
E
[-r-
43
40
0
Av. rework time (Project A)
Av. rework time (Project B)
30
23
20
c
12
<10
M10
0
1-5
6-10 11-15 16-20 21-25 26-30 31-35 36-40 41-45 46-50 51-55 56-60
Week
Figure 10.24 Changes in Rework Time (Projects A and B)
Average Time Spent on One Occurrence of Rework and Week (Project C)
50
47
45
0
40
I
=3
0)
35
w
E
I
30
25
(D
CD
Mi
00 23
20
17
15
-.-
--
10
5
0
A''
1-5
'
6-10
11-15
16-20
21-25
Week
Figure 10.25 Changes in Rework Time (Project C)
108
26-30
10.3.8 RE-INVENTION
Re-invention was identified only in Project A, and the identified primary root cause for it
was scattered locations. An engineer spent long time on a function that was similar to the
one developed by another engineer.
10.3.9 HAND-OFF - WASTED ENGINEERING HOURS BY CAUSES
Figure 10.26 shows the relationship between wasted time on transportation and the
corresponding causes. Transportation was significant in Project C, and the most important
cause was "Absence of task owner." This represents the situation in which an engineer is
forced to leave his/office for some period, and another engineer has to take over the absent
engineer's tasks. This happened to Project B as well. Hand-offs take long time, especially
when the previous task owner is hard to reach. Frequent hand-offs, however, leave
documentation that may be helpful in the future.
Wasted Time on Hand-Off and Causes
60 53
50
-37-
-
40
32
0)
CD
E
M Project A
O Project B
30
0 Project C
20
E
-
--
_
-
14
10
10
CU
E
00
C-
3'
0
-o-C
0
C
CD
CL
0
0,
0
.C
.
-
CE
co
E
CUO
ai)
oU)
0
0
Causes
Figure 10.26 Normalized Waste Time on Hand-Off per 50 Engineering Weeks and the
Corresponding Causes
109
10.3.10 DEFECTIVE INFORMATION
(1) Wasted Engineering Hours by Causes
(i) Under processing / errors/ lapses was the most significant cause for defective
information in all the three projects (figure 10.27), and the amounts of waste time in
Projects A and C by the cause were similar. Under processing means that something is
missing in the output of a task: a task that was considered to be complete is not actually
complete. (ii) Under qualification was the second significant cause for wasted time on
defective information in Projects A and C. (iii) Insufficient communication was the third
significant cause in Project A.
Wasted Time on Defective Information and Causes
700
608
600
500WC:
C~)
400
O 30
EProject A
_____
OProject B
M Project C
E 200
17
100
3:
U13
S0
0
111.5
00
00
o)
W0
Q
240
0
W
CL8
0
0
2) k
C.
Causa
)
00
0.
0 00
0)
0)
0
0
0 013
aEd Ca
0
4)~
Figre
00 8
0
o
eetv
V4)7
(
4)
C0
nomtinpr5
.0
00.lzdWseTm
niern
Causes
Figure 10.27 Normalized Waste Time on Defective Information per 50 Engineering
Weeks and Causes
110
(2) Discussion
Although Projects A and C similarly suffered from (i) Under processing/ errors/ lapses, the
mechanism of how they wasted time was different. Project C's case was specific to
suppliers (figure 10.28). Because Company Y sells key components to Company Z,
Company Y has no reliable communication channel with user companies. This is critical for
them, for how their products are used differs among users, and many users use the products
in the ways the designers have never taken into account. For these reasons, designers in
Company Z do not exactly know every aspect of the specifications of their products. This is
similar to a case in which a user of a key uses it for opening bottles: the user may complain
about a new key that cannot be used for his/her unique purpose. Similar cases are prevalent
in Company Z's market. Company Z sets specifications of new products without
completely covering every use case. Company Y sets more detailed specifications based on
the target specifications given from Company Z. Company's engineers ask questions when
they encounter problems. This usually ends up finding that the task is more complicated
than they thought.
It is difficult for a company in similar situation to Company Y to establish reliable
communication channels with users, for all users are different, and sometimes contacting
users gives users chances to speak up, leading to more workload (adding more features, etc).
However, a part of the 547 hours wasted by (i) was wasted by not knowing the users.
Compared to this amount of time, spending time on establishing good rapport with them
with leading users by periodically visiting them would save a part of their wasted time.
111
The development team in
CompanyY
+--
(supplier of key components)
No reliable
communication channel
Company Z
(Company Y's customer)
Company
Company
Company
Company
Company
A (User)
B (User)
C (User)
D (User)
E (User)
Figure 10.28 Company Y's Relationship with Users - There's Virtually No
Communication Channel with Users
10.4 SUMMARY OF ANALYSIS ON NINE WASTE INDICATORS
*
"
*
Value stream mapping improved in this research was applicable for quantitative
measurements of nine waste indicators in all three projects.
There was no need to add new types of waste indicators.
Three waste indicators (over processing, rework, and defective information)
were more important than the others in terms of wasted engineering hours.
Motion was also significant in terms of wasted time, but analysis of its causes
revealed that trying to reduce time spent on motion is not likely to improve
product development processes significantly.
*
Root cause analysis diagram was helpful for quickly identifying causes for the
occurrences of waste indicators.
*
Quantitative analyses of causes for waste indicators showed different patterns
among companies and projects, proving that this methodology is helpful for a
112
*
company to identify its specific problems.
Additionally, the empirical idea, "Time to solve a
exponentially as time goes by," was valid in all projects.
113
problem
increases
CHAPTER 11: RESULTS OF THE RESEARCH INVESTIGATIONS 2:
ANALYSES ON INVENTORY OF INFORMATION
11.1 OVERVIEW OF THIS CHAPTER
Inventory of information measured in the three projects are compared in 11.2 through 11.5.
Identified inventory of information is classified into thirteen types in 11.6. Three projects
are analyzed measuring inventory by types in 11.7 and 11.8. 11.9 analyzes how quickly
information got rotten in Project A. 11.10 summarizes this chapter.
11.2 NUMBER OF OCCURENCES OF INVENTORY
Figure 11.1 shows the number of occurrences of inventory of information per week in the
three projects. In Projects A and B, six engineers' activities were tracked. In project C, five
engineers were tracked (see table 9.1). Inventory was measured in units of engineering days,
and the minimum measured period was one engineering day. In Projects A and B, on
average, there was one occurrence of inventory per engineer per week. Compared to the
two projects, the frequency of occurrence of inventory was much less in Project C.
114
Com parison of Weekly Occurences of Inventory
7.0
6.0
5.7
-
5.9
CD
a 5.0
w
0
C:
0)
4.0
U Project A
0 Project B
3.0
0 Project C
C:
0
2.0
1.4
1.0
I
0.0
Occurences of Inventory /Eng. Week
Figure 11.1 Number of Occurrences of Inventory of Information per Week
115
11.3 AVERAGE INVENTORY PERIOD
Figure 11.2 compares the average periods of inventory in the three projects. For example, in
Project A, once a task is stopped, it took twelve days on average before it is restarted. This
period is important especially in the contexts in which risks are high (see chapter 8).
14
12
_12
-
10
8
-
0
Project A
0 Project B
C
6
11 Project C
4
2
0
Average Periods of Inventory
Figure 11.2 Average Periods of Inventory
116
11.4 TOTAL INVENTORY TIME
Figure 11.3 compares the total inventory time per engineering week in the three projects.
Project A had five times more inventory time per week than Project C, although the sizes of
the two teams are similar (Project A: six engineers, Project B: five engineers), and they are
both in the same development phase.
Total Inventory Time per Eng. Week
70
64
60
50
Project A
4
30
0
Project B
Project C
W 3
20
10
0
Total Inventory Time / Eng. Week
Figure 11.3 Total Inventory Time per Engineering Week
11.5 IMPLICATIONS
The result of total inventory time showed that Project A had a substantial amount of
inventory time, indicating that the team suffered low throughput. This situation resembles
that of manufacturing processes in 1980's, in which factories had huge amount of
work-in-process inventory. Goldratt (1984) attributed the situation to inappropriate
performance measurements that was prevalent then, claiming that measuring efficiencies of
machines did not lead to improving productivity, but lead to unsynchronized production
processes with huge amount of inventory. He recommended, in his theory, TOC, to measure
inventory instead of efficiencies of machines.
Today, engineer utilization levels are monitored in many product development
organizations, or at least observed by project managers and their bosses. Senior
management people tend to think that there is a chance of reduction of number of engineers
117
when they see their people idle, like a plant director who sees workers taking rests. On the
other hand, idle information is not as conspicuous as idle engineers. Rather, project
managers may be blamed if they fail to give their engineers fewer tasks than they can work
on. Goldratt's suggestion was paradoxical in the manufacturing world twenty years ago:
because measurements were focused on measuring utilization levels of machines, huge
amount of inventory was not paid attention although it indicated low throughput of the
production processes. Today's product development organizations may be in the same
situation. Engineers are busy because their utilization level is monitored. On the other hand,
idleness of information, which gets rotten with time, is significant because it is not
monitored.
The results shown in figures 11.3 and 10.1 back up this idea, especially in Project A. In
project A, identified waiting of engineers was only four hours in fifty weeks. On the other
hand, information was waiting (as inventory) sixty four hours per engineering week.
Projects B and C had the same tendency, although they are not as significant. These results
imply that today's product development processes are in similar situation as manufacturing
processes twenty years ago. Toyota production system has seven wastes (Ohno, 1978).
TOC has only three metrics: throughput, inventory, and operating cost (Goldratt, 1984).
Toyota production system tries to control both waiting and inventory, while TOC ignores
waiting. The results in figures 11.3 and 10.1 implies that today's product development
activities are so premature as manufacturing a few decades ago that applying all the seven
wastes in product development is too early. The more detailed analysis of inventory in 11.8
reveals the existence of striking similarities in manufacturing processes a few decades ago
and Project A's development process.
118
11.6 CLASSIFICATION OF IDENTIFIED INVENTORY
The identified inventory of information falls into the thirteen types as follows:
(1) Type 1: Taking care of a more urgent task in the project
(2) Type 2: Switching to a higher-priority task outside of the project
(3) Type
(4) Type
(5) Type
(6) Type
(7) Type
(8) Type
(9) Type
(10) Type
(11) Type
(12) Type
(13) Type
3: Waiting for information from another task
4: Review/ testing work
5: Day off
6: Maintenance of Documents
7: Rework discovery
8: Other engineers' availability
9: Downstream engineer's availability
10: Waiting for an answer
11: Ambiguous information
12: Limited availability of tool/board/system
13: Others
119
..........
. .........
.....
........
...
..............
..
(1) Type 1: Taking care of a more urgent task in the project
This occurs when a group/ an engineer needs to stop working on a process and switch to
another process in the same project because the latter process has higher priority. Typical
appearance of this in VSM is shown in figure 11.4.
interruption
interru tion
Figure 11.4 Example of Type 1 Inventory
Example from the investigation
1328 in figure 11.5 is an example of this type of inventory of information. The
implementation phase of XXX FW (XXX is a function's name; it cannot be shown due to
the confidential agreement with the company) had not been worked on for five days
because the engineer needed to finish the documentation of another task. He needed to
switch to the latter task because its due date was closer than that of the implementation
phase of XXX FW. As can be seen in figure 11.5, XXX FW was interrupted several times
mainly by tasks inside of the project.
120
..
..
............
0
2/24
3/3/03
40
:3/10
40
40
32
3/24
40
:3/31
0
4/7/03
Rework (ohl
W332
Ider Prdcessirx
XXXXX Port
(t ) "335
(ation
3
8
Ba
m
3
Motion
(ph)
w3411
ors
w333
8
Defective i fo (8h) w334
Undlerpr
2
ed
2
8
3 IE
- 9ore ski
U
10
i325-4d
y
4 Motion 46
8
Rework (3 )
w330
be
4
328-5day
Motion (20h
RIO
Defectiv Info
(3h) w33
Work
i329-3day
3388
28
7 (
12
11X
10
359-1 ay
43
3-day
Rework (23h) $39
Task turned out 10 b m
we complicated than ffw Defective Info (23h) w340
had expectdd
Undler Procslng
Figure. 11.5 1328, Inventory of Information at the Center of This Figure was Caused
by an Interrupting Event from Inside of the Project (Engineer Y, Weekil)
121
3
(2) Type 2: Switching to a higher-priority task outside of the project
This type is the same as type (2) except that the interrupting processes do not belong to the
project. The typical appearance of this in VSM is shown in figure 11.6.
A
k
r
7
interruption
-
Figure 11.6 Example of Type 2 Inventory
Example from the investigation
1408 in figure 11.7 is an example of this type of inventory of information. System-Level
Services Task was interrupted by a supporting work for another project. This interruption
caused i408.
122
. ............
16
4,
407-12day
Workstation
10
34.5
20.5
411-1d
Motion (6h) W*42
XXXIXXX -D $cumenting
12/
XXX OeM I'/
reset pe
IRS
5
7 *
T?)
Moo
w401
X8 X - Doom I"g
2day
Moto 0h)w,
0408-4day
1
03
Documnyfng
Ji8.5
5
W91 Oday
ework (4.51 w404
Defective Info i 4.5h) w405
Underprom
0
13/11 42.5
11/4/02 24
111
44.5
11125
36
12/2/02
39.5
12/9
Z2
16
9
16
15
40.5 12/16
_15-7day
1Rework (1 h)0
31
Figure 11.7 Example of Switching to Higher-Priority Task outside of the Project System-Level Services Task was Interrupted by a Support Work Outside of Project A
123
. .
..
.....
. .....
(3) Type 3: Waiting for Information from another Task
This type of inventory is incurred when a task needs information from its dependent task(s)
to be processed further. The dependent task may be worked on by the same group/ engineer
((3)-i in figure 11.8) or by different one ((3)-2 in figure 11.8). In this classification, not
only waiting for information, but also for hardware prototypes that had been developed
through the project is also included because what software engineers need is the
information whether their software works on the prototype hardware.
Inventory (3)-1
Inventory (3)-2
Figure 11.8 Waiting for Information from another Task
Examples from the investigation
(1) Example of Inventory (3)-1
Figure 11.9 shows two appearances of inventory of information of this type. The two tasks
circled in this figure were testing processes; both needed an updated prototype of a
hardware component that had been developed by the hardware development team.
Especially, i539 was kept for as long as fifty four days because the hardware component it
was waiting for had been redesigned due to serious defects.
124
-
----- --- -------
-
5/19
51.5
/26
J2
t - -
-- - --
6/9
---
.
.
....
........
47.5
47
. .......
.
7/7/03 !)
46
&JO0
52.5
6/24
549-18oa
i!43-3day
lay
8
52.5 6/2/03
---- -
10
8
22
26
13
Up ated
Rewrk (29h) w533
wstructure
change
*
MM9*U
539-58dciy
M**Q
550-12day
4
540-34day
ft
+'f
35
32
8
M....+
Figure 11.9 Example of Inventory (3)-1 - The Two Tasks Circled in This Figure were
Both Testing Processes.
125
.......
. .
.................
(2) Example of Inventory (3)-2
Figure 11.10 shows an example of inventory (3)-2. The task in the dashed circle was left
untouched until the downstream task got all the information it needed.
12
pec Chafge
432-24day ,
XWI -
XXX
t431-21day
20
4
4
XXX
16
k dut to change (updated
FXXX CAL)
mwork (40 .h) w421
Rework 8h) w42
Trouble *hofing
Spec. change
Rework (43h) w421
Spec Change
)08"te
2
Rew
'XXX of XXX CAL)
R eDor Def u
20
45
sequencer
20
er Proces
(0' h) w427
Defects ir
Reworl (3415h) w418 N
*u
Trot
Over
S(345h) w419
in
430-4ca
24
475
HJW
0
36.!
9
i442-28day
9.
34
5/5/03
i638-Cday
40 34
I
i/26
51.5
i541-5day
542-4
3y
52.5 6/2/03
iE43-3day
1
616
2 .u*4
4
2
52.5
i54C48daytI
Figure 11.10 Example of Inventory (3)-2 - the Task in the Dashed Circle was Left
Untouched until the Downstream Task Got All the Information It Needed.
126
. ...........
. ..............
(4) Type 4: Review/ Testing Work
This type of cause was separated from type 1 because review/testing task had often (25
times) appeared throughout the development phase (figure 11.11). Review/ testing work has
high priority because of the following reasons:
- Conducting it earlier reduces rework discovery time.
- Several tasks may be processed based on tentative information from the task yet to be
reviewed.
- Some types of reviewing involve several busy key-players, causing difficulty in making
date changes.
Examples from the investigation
Figure 11.11 shows examples of inventory of information caused by review/ testing work.
1016 was caused solely by an external specifications review work. The interrupted task was
additionally interrupted by two other external specifications reviews, one code review, and
some other tasks. Since this engineer's role is working manager, he could scarcely have
concentrated on one design task without interruptions.
i
'4-100day
1.5
9.5
008-80day
R
009-Cday
016-2day
USA
h)
19
Motson
ransportation
of fnfo (0h)
w022
transfer
C4I day
Bw3
*Tei
15
15
w39
S)
Motion (Ih)
w037
Motion (3N
W035
7
al
038
-
Proect
T
T*stinWQC
n
(XXX)
3.5
5 5
Motion (9h)
Te
Rc
1
ede
3
11
Tra
222
.
2 5
Docurnenting
024-12day
023-30day
8Architectre
Ohter Meeting
Fig-130car
24
;60
021-day
Knowedge
Motion. (4b)
4
155
a
E
Figure 11.11 Example of Inventory Caused by Review! Testing Work
127
1.5
(5) Type 5: Day Off
Although day offs is not waste of engineering hours, they cause inventory of information.
Figure 11.12 shows an example of inventory caused by day off - XXX DC CAL Design/
Implementation task was interrupted by a week off. Since the engineer took a week off then,
the total labor hours was zero (see the number in orange in figure 11.12).
84
38.5
405-3da(
I --- __0
a 16
8
Worksatio
8
401-24ay
FW Cornamon (0#TI )
Motion (ih) w401
XxxOXXX - Doou
ng
43
02- iday
,4~8-4da~
14.5
~465-13day
xy )(XX CAl U1
8
26
iA
Q-d
8 435-3d y
34
38.5 10/7/02
34
10/14
42
10/21
44
10/2t
o
4/4/02
24
11/11 42.5
1/111
11/25
Figure 11.12 Example of Inventory Caused by Day Off - PMU DC CAL Design/
Implementation Task was Interrupted by a Week Off.
128
(6)Type 6: Maintenance of Documents
As is shown in figure 11.13, this type of inventory appears when engineers postpone
documentation and its completion. Although Glodratt (1997) argues that documentation
should not be done immediately after every task because it can cause delay on the critical
path, delay in documentation could incur time to remember and memory loss.
Inventory
by
caused
postponing
documentation
Inventory
caused
by
postponing
completion of
documentation
Figure 11.13 Inventory of Information Caused by Maintenance of Documenting
Example from the investigation
Figure 11.14 shows examples of inventory of information caused by postponing
documentation.
129
:w-= ' '-
-
.............
-.-
............
(discussion)
Hand-off (Rh)
6
340-1 day
45
ty s eem s
f lack of
'afrtow
8/
to bea*
355-26da
expeft
21
w,t f*W
[
2fee
Ie
3 Moti3n (3h) w371
i
o(
nh
36
Redesign
4.
Rbwoi
~
o~ ~
Ti
Pr pro
~
~
~
(1)w6
w to anveTs
20
ng
~
354-14day
Second alar) suppressed
by Mr X H'W team is
busy
procrastinatethis issue for
21
extremely
20
'41-1,r
'-.
!Y I IRework
21.5
0
45
(
i4
XX Online
n~ow on"8/
PPLInrs
Test
6
(31h) w3W
Defective information
(3 1h) w366
Test
w367
information (31h) w368
Rework (31h)
3
29 Defective
Moion (3h) w369
H
sunderstandinps
tified
1/03
50
8/11
50
8/18
50
8/2S
50
9/1
47.5
9/8
47
9/15
39
9/22
39
Figure 11.14 Example of Inventory of Information Caused by Maintenance of
Documenting
130
9/2!
. ....
...... ......
(7)Type 7: Rework Discovery
This inventory appears when a task that was perceived to be completed is reworked (figure
11.15). Since this inventory is related to rework discovery time - one of the important
metrics in system dynamics - reduction of this inventory could prevent rework caused by
"upstream changes" (pp. x) and rework caused by "working on unreliable/defective info."
I
Rewor is
discovered
Perceived to be
completed at this
time
Figure 11.15 Inventory of Information Caused by Rework Discovery
Example from the investigation
Figure 11.16 shows an example of inventory of information caused by rework discovery. In
this case, a task needed to be reworked because the engineer was notified a change in H/W
design on which his task was dependent.
131
.............
......
.........
10
Rework
630-4day
527-18day
528-7day
-eay
53 4
.
Rework (28h) w526
to HW design Change. other
.5h)
Rework due
DeteI,? Info
(11.5h) w520
Und rocessing
25-
26
188
18i
12d
14
Get U
ay
XX3td
i532-1%day3
i1day
9
I.
j534-
533-3day
n
2
xxxx
Diag Enhaoceent,
5
Processing
w525
9
Discussion
(4hJ
7
544-3d
C46- day
Diag
Reiease
MgL.
Rele~e Mgt
Re
M otin (1h)
XX
w527
44
Rees
Mgt.
Meeang
547
Motwn(2h)
w528
Mseng
6
Figure 11.16 Example of Inventory of Information Caused by Rework Discovery
132
.
............
-- --------------
.. .......
....
. ..
......
. ..
(8) Type 8: Other Engineers' Availability
Example from the investigation
Working in a team, sometimes tasks need to be stopped until its output is confirmed
acceptable for the upstream engineer. This can take long because the needed engineer may
have some high-priority tasks. Figure 11.17 shows an example of this type. In this case, the
testing task needed to be reviewed by another engineer who is taking care of its dependent
task. If the needed engineer is to process a downstream task, inventory of information is
classified as (9): downstream engineer's availability.
50.5
F'3 03
46
3/17
31 0 50
33.5
46
3/31
3124
417/03
464114
43
4/21
4
A27-5cay
Still undesv-abte
output - due to
XXXX unit
problem
'I
"4
Inquery
a6
~~cy
4
-----
ewortk (OnFw44i
r Processing (10h) v413
411
a
obwotng
-
a
1ework
day
(1
428-32day
M414
10
20
44Ot -
Over Processing (10h) w415
H/W version
421-14day
control
Unnecessary troublshooing
Work on enmeous informatin
(1wk)
G
'- d
w41
(41.5h)
SUnidendied ta.
SRework
*
- Processing (25h) w416
Working with wrong H/W
status
status424-8day
prernatur investigation
Extended features' commrands
Transportation (67.1
(XXXXXXX)
-
424-dy
4qrmatting to XX
10
Figure 11.17 Example of Inventory of Information Caused by Other Engineer's
Availability
133
r
......
..............
. ...........
......
(9) Type 9: Downstream Engineer's Availability
As is shown in figure 11.18, this type of inventory appears when handed-off information is
left untouched for some period.
Downstream
engineer
is
not
available for task B.
Figure 11.18 Inventory of Information Caused by Downstream Engineer's Availability
134
-- --------------
Example from the investigation
Figure 11.19 shows an example of this type. In this case, it took nine days before the
engineer used the information from the H/W team.
Wk6
5
i)
3
321
2/10
Wk17t
Wk7
(Wk18)
Wk12
3/17 (Wk23)
Wk11
Wk1O
Wk9
Wk8
2/17 (Wk19) 2/24 (Wk20) 3/3/03 (Wk2l) 3/10 (Wk22)
Wk1
3/24 (Wk21
2128
eat re Change: beca e
a
tha it cannotwb
reak d byH/W, soit was
deci
to 6e realized by
$/W
Canni
ol defecti 'wH/W
puse
Still undesirable
output - due to
XXXX unit
problem
,4n mnas ae
XXXX DC CAL
Inquery
_
2$)
2
42C
wk (3t
OV11 r Pro
wi)
I
I
ReWork (5h) w44i
(
*r Processing (10h) i 413
1 roubieshooting
sing (3hj w411
(
I\
i4 T-2day
T*1(
6
-A)
-
-
-*
26
-work (3h) w409
Processing (3h) W40
Troubleshooting
efective info from the
Ys.earn (HW)
15.5
-1
1ework (10
K. CAL
3.
'14
10
Over Processing (10h) w415
20
TcTmenting
12.5
HAN version
contil
C
I
8
Work on erroneous information
fw Common- Resoui ce
Constraints Check
S 1542-dy
otion (5h) W4 13'6474 1c?
D
"I
421-14day
F
14k)
OV
.r
Processing (25h) w416
Worting th wrog HAN
status
..- lda
/'T' -
0423-10
Figure 11.19 Example of Inventory of Information Caused by Downstream Engineer's
Availability
135
17.
.
.......
..
...............
(10) Type 10: Waiting for an answer
As is shown in figure 11.20, this type of inventory occurs when an engineer finds a
question, which takes some time before he/she gets an answer for it.
/ swer
Inquiy
Inventory of information caused by
waiting for an answer
Figure 11.20 Inventory of Information Caused by Waiting for an Answer
Example from the investigation
In the case shown in figure 11.21, the engineer found an error that was not caused by his
software. Thinking that there is something wrong in the hardware, He reported it to the
H/W engineer. The task could not be processed until this software engineer got an answer.
136
.
of
A :2/24
=2ate
iffpy
,u
!
ition
Canne
se
rfect b
a1seW
de"
/03
46
33.5
3/17
3/10 50
3/24
46
3/31
46
4/7/03
MW
i427-5day
StIl
undesirible
output - due to
XXXX urnn
problem
'liz
(2*
30ev ork (31,
Ove r Proce
50,5
......
...
...........
....
....
. ........
.........
.
Inquery
42C-!
- -------
17
ay
Rework (5h) w44
'er Processing (10h) i P413
reshootng
;silg (3h) w41 I
TroubU
U6-
Xx
K.
CALI
20
Rework (41.5
Over Processing (10h) w415
H1W version
contoI
premature
i421-14day
Extended fe
(X:
425-63day
Unecessaiy omeesnocong
8
escul
heck
4
10
Work on errofleos mnfomnation
o 15w2
otion (Sh)
1wk)
1W2
go,
.
4
o
r Processing (25h) w416
Working with wrong 8/W
status
424-8day
Figure 11.21 Example of Inventory of Information Caused by Waiting for an Answer
137
..
.........
......
. ..........
......
........
=
-
......
...
(11) Type 11: Ambiguous information
This type of inventory of information occurs when engineers find the information on his
hand too unclear or unreliable to be used.
Example from the investigation
In the case shown in figure 11.22, an engineer stopped processing two tasks because he
found the related specifications unclear.
XXX
A
12
i432-94day
Lin
work (40 5h) w421
20
rt
431-21 day
Ax
Re Dort De
42i32day
Specchange
Rework
Trouble
X
4
45
20
A"
24
ranspoitation (67.5h)
1
R
40
fting
Stop due to .ncdear sp
sequencer
3ring
XX ftrMat
-410
-
3
430-4day
204r2 1
40,514.4/28
1034
5/5/03
Reworl
(34.5h)
Trot
Over
Fless
4Error
w4 18
(34.5h) w4 19:
7nin
40 3A 5 5/12
442-2eday
68
?1
51.5
5/26
52.5 6/2/03
Figure 11.22 Example of Inventory of Information Caused by Ambiguous Information
138
..
........
.
........
..
......
..
.....
. ..
(12) Type 12: Limited availability of toollboardlsystem
Example from the investigation
In the example shown in figure 11.23, a limited number of prototype H/W boards were
shared by the software team, causing inventory of information against engineers' will.
Aotion (116h)
I16*~)
dotion ~fQC
Testin
Testin4
1
C
itsourc
A4U
Conm Selease
Refusal
10fusal
nomp deqink test
Revio
Motion
(5.5h)
w1 54
Derectime Info. (62.$)w156
An Error in wnwareI
for X
Wnfing
6
I Test
10
62.5h) w15
TMAub2s
I pP
117-12day
11 1&53day
'jFj ,,
b
7jta
7
? I
30
ili 13-45day
Rework (20h) *157
inventory due to
11mita aila
Spec change Adkd A feat i
f
.
of PP boad
* in
DSP FW
Dk§P
Debug
I
DPCo t
Firm*a
Cotppiwd
4/03
,
7/21/03 37
7/2q
PPd7.
P
ink WAt
AC
-
2
08
AF
8403
i122-3day
21 -
12
50
8/11 50
2n
FW (sngle-sfte)
19-10day
i
23-2day:
20
20
8/18
d
ay
52
8/25
47
911
1)
Figure 11.23 Example of Inventory of Information Caused by Limited Availability of
Tool/Board/System
139
11.7 DISTRIBUTION OF INVENTORY TYPES AMONG ENGINEERS
Figures 11.24, 11.25, and 11.26 compare the distributions of types of inventory of
information by engineers. These results revealed that the distributions differ among
engineers and projects.
Distributuion of Types of Inventory (Project A)
100%
90%
M Others
80%
0 Limited availability of toot/board/system
M Ambiguous information
70%
.. .
.
-
60%
50%--
-
-
-
* Downstream engineer is waiting for other necessary
information
EB Other engineers' availability
-
-
-
..
.~
40%
E Waiting for answer
.- .-
~
--
..
[t Rework Discovery
E Maintenance of Documents
~
.
E' Day off
-
- -.
.- --
30%
-
. ~~
..
20%
- ..
--
---
~ ~ ~ ~
. .-
--
.
9 Waiting for information from another task
.
-
.-
.
[t Review/Testing Work
U Switching to higher-priority task outside of the project.
-
0 Taking care of a more urgent task in the project
- -
...
10%
0%
U
F
H
Y
T
M
AH
Engineers
Figure 11.24 Distribution of Types of Inventory (Project A)
140
Distributuion of Types of Inventory (Project B)
Ut Others
N Limited availability of tool/board/system
100%
N Ambiguous information
-
90%
[ Waiting for answer
-------
4 80%
U Downstream engineer is waiting for other necessary
information
M Other engineers' availability
-
O Rework Discovery
70%
0 Maintenance of Documents
60%
-
0 Day off
1II Review/Testing Work
50%
* WWaiting for information from another task
40%
N Switching to higher-priority task outside of the project.
O Taking care of a more urgent task in the project
30%
-----
20%
10%
0%
U
Y
T
F
N
J
All
Engineers
Figure 11.25 Distribution of Types of Inventory (Project B)
141
Distributuion of Types of Inventory (Project C)
100% r
U Others
90%
N Limited availability of tool/board/system
-- 1 Ambiguous information
80%
EO Waiting for answer
70%
* Downstream engineer is waiting for other
necessary information
* Other engineers' availability
60%
* Rework Discovery
50%
E Maintenance of Documents
40%
E3 Day off
-
30% -
U0 Review/Testing Work
ISWaiting for information from another task
20% -
10%
* Switching to higher-priority task outside of the
project.
O Taking care of a more urgent task in the project
--
0%
KZ
NF
HS
HG
All
Engineers
Figure 11.26 Distribution of Types of Inventory (Project C)
11.8 ANALYSIS ON INVENTORY OF INFORMATION BY ITS TYPES
11.8.1 NUMBER OF OCCURENCES
Figure 11.27 compares the three project's number of occurrences of inventory by types. In
Project A, type 1, taking care of a more urgent task in the project, was the most frequent
type of inventory. In Project B, type 2, switching to higher-priority task outside of the
project, was the most frequent inventory of information, implying that the engineers were
frequently interrupted by other commitments. Project C had no outstanding type of
inventory in terms of number of occurrences, the most frequent one being type 1.
142
Occurences of Inventory per 50 Eng. Weeks
140
129
125
120
(D
0)
--------
100
* PorjectA
------_
O ProjectB
0)
0 ProjectC
79
80
0
C
)
60
47
42
40
29
27
18
20
I
=- - M '
0-
0
CD
0
-
-
0
Q
'S
0e
,
4.9
2
E
0
--- 44-o
0
2
---- 00
-0
-
C
0C
E.-0
Ty p
>
C6
Cuc
2
0i
0or-
5
C
o0o
E
C
S
<( S
CU
c
0J
0
Types
Figure 11.27 Normalized Occurrences of Inventory of Information per 50 Engineering Weeks and the Corresponding
Types
143
11.8.2 AVERAGE INVENTORY PERIODS
Figure 11.28 compares the three project's average lengths of inventory by types. In Project
A, "Ambiguous information (type 11)," "Rework discovery (type 7)," and "Waiting for
information from another task (type 3)," were the most outstanding ones with about the
average of forty engineering days. This is because the embedded software team depends on
its upstream process, hardware development. Rework discovery sometimes take long time
because some types of bugs in software cannot be identified without hardware prototypes.
Software engineers sometimes suspend their tasks until prototypes become available.
Project B had much less average inventory periods of the three types above. This was
mainly because there were no major changes in hardware specifications. Project C was
similar to Project B in terms of the three types of inventory, for the project did not involve
major hardware changes. In Project C, downstream engineer's availability (type 9) caused
the longest average inventory period, 21 days. This implies that Project C is managed in a
way not to interrupt engineers.
144
0
z
0
9
9
0
9
0
9
00
9
~tQ
CD
(1)
Total
Others
Limited availability of tool/board/system
Ambiguous information
Waiting for answer
other necessary information
Downstream engineer is waiting for
Other engineers' availability
Rework Discovery
Maintenance of Documents
Day off
Review/Testing Work
task
Waiting for information from another
of the project.
Switching to higher-priority task outside
the project
Taking care of a more urgent task in
9
oI~
9i
WN
S0
o
Er
o o >
0
0n CD
o
C0
0
CD
0) 0
01
~4
0) 0
41-
C>
.P.-
Average Inventory Time [eng.day]
(D
0.
0
CD
CD
(D
11.8.3 TOTAL INVENTORY TIME
The overall inventory time by types is shown in figure 11.29. The two most significant
types of inventory in Project A were "Taking care of a more urgent task in the period (Type
1)" and "Waiting for information from another task (type 2)." The two types take about 2/3
of the total inventory time of Project A. Project B had the longest inventory time in
"Switching to higher-priority task outside of the project" (type 2) of all the three projects.
11.8.4 OVERALL DISCUSSION
Figure 11.30 describes unsynchronized production processes described in "The Goal"
(Goldratt, 1984), in which throughput is low although all machines are busy. Goldratt
attributes this situation to the production management prevalent in 1980's, in which
inventory is not measured. In such unsynchronized production processes, the measurements
of utilization levels leads only to local optimization, leading to production of huge amount
of work-in-process inventory. In figure 11.30, WIP (a) is waiting because Machine A is
busy with other WIP. WIP (c) is waiting because other parts necessary for assembly are
missing.
Project A is in a similar situation (figure. 11.31). WIP (a) in figure 11.30 corresponds to
information inventory (a), which is type 1 inventory and WIP (c) in figure 11.30,
information inventory (c). Therefore, Project A, with high amount of types 1 and 2
inventory, is considered to be as less productive as the manufacturing process in figure
11.30.
Morgan (2002) listed "over utilization" as one of twelve product development process
wastes, arguing utilization level over 80% significantly decreases the system's throughput.
Project A's unsynchronization implies that the project chronically suffered over utilization.
146
-1
0
9
0
9
0
9
U)
CD
Total
Others
Limited availability of tool/board/system
Ambiguous information
Waiting for answer
Downstream engineer is waiting for
other necessary information
Other engineers' availability
Rework Discovery
Maintenance of Documents
Day off
Review/Testing Work
Waiting for information from another
task
Switching to higher-priority task outside
of the project.
Taking care of a more urgent task in the
project
i
0
N>
o
U0I
o~
o
N)
0
0
coz.
.
0
0
:
C.,
C.co
C
0)~
0C
OD
C)0)
0
0
Inventory Time [Eng. Day]
OD
Cn
C)
CD
U),
CD
C,,
CD
CD
m
CD
CD
CD
.
.
. .............
...............
WIP (c) is waiting because
......
. . . .........
WIP (d)
other parts are missing
Customer X
XCustomer Y
WIP (a) is waiting because the
Machine A is busy with other
WIP
..- --,-
WIP (c)l
Customer Z
4
Machine B:
WIP (a)
Empty!,'
Hight
BUSY
Li'
Machine B is
represents
2
producing
number
unnecessary
-AI
WIP because
stoppage is to be
penalized
WIP (b)
Huge inventory
of final product
because of the
product was
not pulled by
the market or
lost its value
because of too
long lead time
Machine A:
BUSY
Machine A needed to
stop working on (a)
Paradox
because working on (b)
Low throughput of value (products that
was necessary to fill the
can be sold at high price) in spite of
empty bin.
every machine's high utilization ratio.
Figure 11.30 Unsynchronized Manufacturing Process Described in "The Goal"
(Goldratt, 1984).
148
.....
-----
Info. Inventory (c) - type 2
Information is waiting for other
L!i
necessary information.
Customer X
Info. Inventory (a) is waiting
because Engineer A is taking
w---Customer Y
care of more urgent task: info.
__44k
inventory (b).
Info. Inventory (a) type I
'' Customer Z
iT
Engineer B:
Empty!
,'
BUSY
Hight
represents
Low-value
product
Machine B is producing
inventory
unnecessary information
because his/her utilization
level is monitored in some
ways
tEi
Info.
Engineer A:
Inventory (b)
BUSY
Engineer A needed to stop
working on (a) because working
Paradox
on (b) was necessary to create
Low throughput of value (products that
the information engineer B
can be sold at high price) in spite of hard
wanted.
working of every engineer
Figure 11.31 Unsynchronized Development Process of Project A
149
11.9 ROTTEN AND FRESH INVENTORY
11.9.1 RATIO OF ROTTEN INVENTORY AND TIME
Investigation in rotten inventory was performed based on the idea described in chapter 8.
Figure 11.32 shows the percentage of rotten information identified in Project A; only 5 %
was found to be partially or completely rotten. Figure 11.33 shows changes in ratio of
rotten inventory of information with time. This figure reveals that the ratio of rotten
inventory increased with time, and almost twenty percent of information got rotten when it
was kept for three to four engineering weeks. Figure 11.34 shows the trend line of the
relationship between the ratio of rotten information and time. The trend line was the
following:
y = 0.0054x + 0.8094
(Equation 11.1)
Ratio of Rotten Inventory to Fresh Inventory (Number) of
Ocurrences
5%
* Rotten
* Fresh
95%
Figure 11.32 Ratio of Rotten Inventory of Information in Number (Project A)
150
Ratio of Rotten Inventory
I
100%
90%
80%
70%
60%
0 Fresh Inventory
02
50%
0 Rotten Inventory
40%
30%
20%
10%
0%
-j
1-3
4-7
8-10
11-20
21-30
31-
Inventory Time [Eng. Day]
Figure 11.33 Changes in Ratio of Rotten Inventory of Information with Time
(Project A)
151
Ratio of Rotten Inventory and Inventory Time
60%
y = 0.0054x + 0.0356
50%
*
R2 =0.8094
40%
-
--
30%
0
02
10%
0%*
0
20
40
60
80
100
Inventory Time [Eng. Day]
Figure 11.34 Trend Line of Changes in Ratio of Rotten Inventory with Time (Project
A)
152
11.9.2 RATIO OF LOST VALUE IN ROTTEN INFORMATION
Rework Ratio can be calculated with the following equation:
Rework Ratio = (Time Spent on Rework)/(Time Spent on Original Work)
(Equation 11.2)
Figure 11.35 shows the relationship between rework ratio and inventory time of all the
rotten information in Project A; there was no strong correlation between them. The
average rework ratio was 53%.
Rework Ratio and Inventory Time
100%
90%
80%
0
0
(D
3:
Of
A
-
A
A
A
-AA
70%
60%
50%
--Average:53%
A
40%
A
30%
20%
10%
A
A
0
20
40
60
Inventory Time [Eng. Days]
Figure 11.35 Changes in Rework Ratio with Time
153
80
100
11.9.3 MONTHLY INTEREST RATE CALCULATION
Because the rotten inventory increased linearly with time (equation 11.1), and the rework
ratio had no correlation with time, inventory of information can be considered to have some
interest rate. The monthly interest rate can be calculated with the following equation:
0.0054[/ Eng. Day] * 21 [Eng. Day / Eng. Month] * 0.53= 6% [/ Eng. Month]
(Equation 11.3)
This implies that if information is kept as inventory for a month, engineers need to work
extra 6% on average to make up for the loss.
This interest rate is considered to be useful for re-designing organizational structures:
products in the highly unstable market should have processes in which the amounts of
inventory of information are minimized.
11.9.4 TYPES OF ROTTEN INVENTORY -- DISTRIBUTION OF TYPES OF ROTTEN
INVENTORY
Figure 36 shows the ratios of rotten inventory by their types. 56% of "Rework discovery"
(type 7) were rotten; 44% of rework discovery occurred due to hidden errors in the
information itself. Rotten information was also identified in waiting "Waiting for
information from another task" (type 3), "Day off" (type5), "Switching to higher-priority
task outside of the project" (type 2), and "Taking care of a more urgent task in the project"
(type 1).
154
Ratio of Rotten Inventory
.2
0T
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0 Fresh Inventory
(Number)
* Rotten Inventory
(Number)
-
-
0 -~
CL
C)_
0%
E
-?_1
4
o-c -)
--
-M
0
>l
0
0
M
0
--
-
-
aD
)
0-
-
0
a)
l
-
0
Types
Figure 11.36 Relationships between Ratio of Rotten Inventory and the Corresponding
Types
11.10 SUMMARY OF THIS CHAPTER
Value stream mapping was also applicable for quantitative measurements of information
inventory. Quantitative measurements revealed how much and why engineers' activities are
interrupted - this result can help companies revise their future strategies in project
management, scheduling, prioritization, and resources allocation. The analysis suggested
that Project A' information flows resembled those typical in manufacturing factory several
decades ago.
Rotten information was identified and measured in Project A. On average, 6 % of value
adding effort became waste if the output information had been stored for a month in project
A.
155
CHAPTER 12 FUTURE WORK
12.1. NINE WASTE INDICATORS
The three waste indicators, over processing, rework, and defective information were more
prevalent of all nine waste indicators in the three projects investigated in this research. Still,
the results of three investigations are not sufficient to justify ignoring the waste indicators
that were not significant in them. Performing more case studies, especially fields other than
development processes of embedded software, will be effective for reduction of waste
indicators.
12.2 INVENTORY OF INFORMATION
Inventory of information was found to be prevalent in all the three projects, and the study in
one of the projects revealed that information got rotten rapidly. Although a specific interest
rate was deduced, this interest rate is expected to depend on contexts specific to projects.
Another topic related to the interest rate of information inventory is the exploring the
relationship between the interest rate of information inventory (X in figure 12.1) and the
reduction of released product's value (Y in figure 12.2). X's causes include market,
requirement, and technical risk and Y's cause is market risk. Therefore, X and Y should be
correlated and X should be more than Y. Deducing X needs drawing a value stream map; Y
can be deduced from sales information, which takes less effort. If the correlation between X
and Y becomes known, X, which is useful for re-designing organizations, can be deduced
without detailed analysis requiring value stream mapping.
Information's value
X% LOSS
1 ENG. MON.
Time
Figure 12.1 Interest Rate of Information Inventory
156
Product's value
Y% LOSS
Minor Change
Major Change
Time
Figure 12.2 Reduction of Released Product's Value
157
......
............
......
. ..
.......................
.
12.3 SUBSTITUTING TASK INVENTORY FOR INFORMATION
Task inventory is idle tasks that are ready to be worked on by engineers. Task inventory can
be counted by engineers. It can also be counted with a value stream map; in figure 12.3,
inventoried tasks of this engineer on 2/19 are six. Counting task inventory is easier than
measuring inventory time, which is performed in this research. However, unlike in
manufacturing, time needed for a task varies significantly. And, engineers tend to start
working on the easiest task. Therefore, numbers of inventoried tasks may not have the same
meaning throughout a project. However, investigation of the correlation between
information inventory and task inventory may verify the possibility of replacing
information inventory with task inventory.
4
213
It inventory
21
2a
ILi-07
engineer N s
In ProjecB
hIo
eaClr
Proftty
12
&lay
ctIvlties
0,
4
Ox
-neno-
S 4 th
inventory)
5 inventory
110
4
1
6
irwentory
i 38
71
Q&UfqU
220
8
ur
4
t
e k
__________
1s2
22
:4
i
"
-roto
13
y Meetng
epbn
..
yMee~ng
o on10 h26h40
Figure 12.3 Counting Task Inventory with a Value Stream Map (Project B)
-
Task
Inventory Can be Calculated by Counting Green or Red Lines Crossing a Day.
158
12.4 ARE TOC'S THREE METRICS SUFFICIENT?
Analysis of Project A (see chapter 11) revealed that the project's development process is
similar to the manufacturing process described in "The Goal" (Goldratt, 1984). This implies
that the three metrics (throughput, inventory, and operating expense) of Theory of
Constraints (TOC) (Goldratt) may be sufficient for addressing waste in Today's product
development processes. Verification of this idea needs the following processes.
1.
2.
3.
Defining "throughput" in product development processes.
Test the three metrics for measuring waste in product development processes.
Examine the three metrics address most of waste in product development
processes.
12.5 SHOWING WASTED TIME EXPLICITLY IN VALUE STREAM MAPS
In chapter 7, wasted time was explicitly displayed in value stream maps (figure 12.4).
Although this technique was not applied in drawing value stream maps in this research, it
may make wasted time more distinct from value-adding time.
Wasted time is this period
Creating the sam
information
Non
Value-Adding
Work
Wasted Engineering Time
Figure 12.4 Measuring Time Spent on Overproduction - A Hatched Process Box Mean
Overproduction (Same as Figure 7.1)
159
12.6 EXPLORATION OF ENGINEER UTILIZATION LEVELS
The value stream maps in this research have all the information necessary for measuring
engineer utilization levels. Measuring utilization levels, which was not performed in this
research, may make it clear how utilization levels affect product development processes.
10
20
20
2
t3xxx
311-
7.5
10~ fll
316-300ay
2day
o.
o
fg
~
Motion (7mSo()
3I8-OO
AtaZ
28
10
20
(
xx2
A, Enginer Y
20a
4.
44
(Io
2t
2RW
notthave1
L.2St
Fiur 12
ieSpnnnTskqhw
(Project A, Ehie
160
au Sra
i
Y)
a
CHAPTER 13 CONCLUSIONS
Conclusions from the Perspective of This Research's Goal
" The nine plus one waste indicators for measurement of waste were determined based
on the analyses of causal relationships among various factors of low performances in
product development processes.
" As a result of these analyses, the root-cause analysis diagram was produced. The
diagram was a database of causal relationships among factors of low performances.
"
*
"
The value stream mapping for quantitative measurement of waste was developed
through preliminary case studies. A process for measuring waste with waste indicators
and value stream mapping was developed.
These tools and processes have successfully been applied to three industrial case
studies in two companies, in which value stream maps have been developed through
intensive interviews with project managers and engineers.
The three case studies has proved the following:
* The nine waste indicators were sufficient for identifying and measuring
"
waste in product development processes.
Inventory of information was prevalent in
*
processes.
The root-cause analysis diagram was useful for identifying typical
product development
"
root-causes for waste.
The lean tools and processes developed in this research have proved to be able to
"
identify problems both peculiar and common to the organizations.
Therefore, these lean tools and processes can deliver to product development
organizations information that leads to continuous improvement of their value-creating
processes.
Findings and Implications
*
Among the nine waste indicators, three waste indicators, over processing, rework, and
defective information were more significant than the others, implying the possibility of
reducing the number of waste indicators.
161
"
*
*
It has been proved that time per one occurrence of rework exponentially increases as
time spent on the project increases.
Analysis of inventory of information has revealed that the development processes of
the investigated projects has turned out more or less similar to the unsynchronized
manufacturing processes several decades ago.
In one of the investigated projects, information got rotten at the rate of 6% a month.
This indicates information inventoried for a month causes additional engineering work
by 6%.
162
APPENDIX I EXECUTIVE SUMMARY
1. GOALS AND OBJECTIVES
The goal of this research is to develop a process for continuous creation of lean value in
product development organizations. Creation of lean value means realizing value with
minimum wasteful process.
To achieve this goal, the objective of this research was determined to develop ideas and
methodologies of lean product development into tools and processes that can help product
development organizations (1) identify and measure the waste in their teams' processes; (2)
identify causes and measure their impacts on PD processes; and (3) finally learn the best
strategies to pursue to improve their PD processes.
2. RESEARCH PROCESS
2.1 Define nine plus one waste indicators for waste measurement (table A-1).
Table A-1 Nine plus One Waste Indicators
Description
Waste Indicator
1. Overproduction of Information (Duplication)
Different people/groups are unintentionally creating the same
information.
People are waiting.
2. Waiting of People
3. Transportation of Information
(Preparing and
Information is in transportation.
forwarding information)
C,0
0
4. Over Processing
Engineers create information that won't contribute the value of
product.
Cn
5. Motion of People (Information hunting, travel, reviews,
People have to spend time on non value-adding motions.
documentation, and meetings)
6. Rework
Redoing tasks perceived to be finished for some reason
7. Re-Invention
Designing similar things without utilizing past experience.
8. Hand-Off (Hand-off inside of project)
Information is handed off with its responsibility between two
groups/people.
9. Defective Information (Coupled to Over Processing
Erroneous or incomplete information.
and Rework)
Inventory of Information
i Work-in-process inventory of information.
163
2.2 Create the root-cause analysis diagram that is useful for quickly identify
root-causes for waste (figure A-1).
Waste indicator
Intermediate Causes
4
(effect)
Individual Designer's
Poor Understanding
of Downstream
Tasks
(e - Ma.nutacEperunce
Lack of Constructive
Advice from
Designers
Dasitiners
* Root Cause
rUiications
--
Lack of
of Designers
Designers
IRaaourcea(1)
Expeiencd
~AdvicelAsking
Over
-4System
Insufficient
lsftetlm
Utilzation
Time
No Level Scheduling
FL __
__
About 300
Irgaucauronal
Structure
SpatialStructura
Barrier
Scattering
Locations
typical root
causesin
Outsourcing
Corporate Cultum
Specifying Too
Musch Detail
-]
Ormzational
Comp
Hierarchy
SpatiaVStructurul
Processing
Barie
ScttrinV
Lcaton
F-Lunc.i
Figure A-1 An Example of Root-Cause Analysis Chart
164
total
...
.
. ...
........
2.3 Optimize value stream mapping for measuring waste identified by the nine plus
one waste indicators (figure A-2).
:2/24
40
40
/3/03
3/) 0
17 32
40
3/241
40 1
:3/31
0
4/7/03
Kewor( 415
W332
ider Prdcessin
Otper
122-6d
aon (61)
i323-Aday
V.1-- :
8
%Ii%
Boot Load!4
o (8)
I
XXXXX Port
5
conitments
Inventory 2
Turned
but t
10 63 5-4d
0
'4
xle
awe
54d
324-3day
3388
Overlue
task
(XXX)
34
(3h) w33'
Work n
10
28
Rewor
12
8
Rework (31 )
w330
Defectivf info
4
328-5day
Motion 420h
Mot ion(6 w337
Do
3
- - --~~ ^---
-
9dore ski
w341!
Meetnig
Errors ideitified
1-6iay
8 4
32
3
20
336
w334
330-
i331-2day.m
-.
18*.. '
43
6359-1day
Task turned out to be mucdt Rework (23h) r3939
we cM ttcat n Vi'y Defective Info (231h) w340
hadd
expected.
.
.. Under Processing
.-
Identified
. h"""Waste
Indicators
Figure A-2 An Example of the Value Stream Map for Quantitative Analysis
165
3.
...........
.........
3. RESULTS1: NINE WASTE INDICATORS
The value stream mapping improved in this research made it possible to measure waste
time on each category of waste (figure A-3). These results revealed that "Over Processing,"
"Rework", and "Defective Information" are more prevalent that the other waste indicators.
Wasted Tirnes per 50 Eng. Weeks and Waste Indicators
2500
01500
2357
~
15001438
978
LU
1000
871
760343
o ProjectB
0 ProjectC
24
500
z
135
180
17 12
00
192
94145
111
9
22 0
0
C
0
0
%0.
Waste Indicators
Figure A-3 Relationship between Wasted Time and Nine Waste Indicators
Detailed analyses using the root-cause analysis diagram made it possible to identify
problems specific to each company and show how many hours are wasted on them. (Figure
A-4).
Hardware Team
The verification process
,,
Embedded Software
is not effective.
i.
*
Team
Embedded Software
Team
(Wasted 861 hours)
Flow of defective information
Figure A-4 An Example of Identified Problem
166
One occurrence of rework turned out to take more time near the end of projects than at the
beginning of it (figure. A-5).
Average Time Spent on One Occurrence of Rework and Week (Projects A and B)
80 r
70
67
0
60
Lii
57
50
E
F- 40
-
43
0
0)
-*-Av. rework time (Project A)
-0-Av. rework time (Project B)
30
20
-
-
-
5
10
1-5
23
4
__
06
1
10
6-10 11-15 16-20 21-25 26-30 31-35 36-40 41-45 46-50 51-55 56-60
Week
Figure A-5 Average Time Spent on One Occurrence of Rework
167
4. RESULTS2: INVENTORY OF INFORMATION
4.1 TOTAL INVENTORY TIME
Figure A-6 shows the total inventory Especially, Project A's inventory time was significant:
64 engineering - day inventory time in a engineering week on average (it had 6 engineers).
Total Inventory Time per Eng. Week
70
F
64
60
-
50
ProjectAl
-
40
30
lProject B
Project C
Lm-i
30
20
13
10
0
Total Inventory Time / Eng. Week
Figure A-6 Total Inventory Time per Engineering Week: Number of Engineers in
Projects A, B, and C are 6, 6, and 5 Respectively.
4.2 INVENTORY TIME AND THE CORRESPONDING TYPES
Figure A-7 shows the relationship between inventory time and the types of inventory of
information. As can be understood from this graph, the following two types were dominant
in Project A.
Type 1: Taking care of a more urgent task in the project
Type 2: Waiting for information from another task
This result implies that Project A's development process was an unsynchronized one: In
Project A, although engineers were switching tasks frequently not to delay the project,
many tasks were not able to be started because some information was missing. This
tendency resembles the manufacturing processes several decades ago.
168
9t
rQQ
(I)
CD
Total
Others
Limited availability of tool/board/system
Ambiguous information
Waiting for answer
Downstream engineer is waiting for
other necessary information
Other engineers' availability
Rework Discovery
Maintenance of Documents
Day off
Review/Testing Work
Waiting for information from another
task
Switching to higher-priority task outside
of the project.
project
Taking care of a more urgent task in the
0)
N
(D
-4
I,
-~
.-
0)
0
02i
CD
CD
CD
C)
C-
0)
0)
0)
CD
C)
inI~i~i~i
0)
0
0)
0
o
0)
0D
0
0
0
Inventory Time [Eng. Day]
0
0
-4
CD
0
0
(n
CD
0.
C')
CD
CD
=3
m
-0
CD
~0
CD
4.2 ROTTEN INVENTORY
Figure A-8 shows how the number of rotten inventory increases with time. Figure A-9
shows the relationship between rework ratio and time. Rework ratio is defined by the
following equation:
Rework Ratio = (Time Spent on Rework) / (Time Spent on Original Work)
Monthly interest rate of information inventory can be calculated as follows:
0.0054[/ Eng. Day] * 21 [Eng. Day / Eng. Month] * 0.53= 6% [/ Eng. Month]
If information is kept as inventory for a month, engineers need to work extra 6% on
average to make up for the loss.
Ratio of Rotten Inventory and Inventory Time
60%
y = 0.0054x + 0.0356
50%
_--
0%
2,
-_
R
_
> 40%
_
=
0_
2
-
30%
020%
-
-
-
-
10%
0%
0
20
40
60
80
1001
Inventory Time [Eng. Day]
Figure A-8 Trend Line of Changes in Ratio of Rotten Inventory with Time (Project A)
Rework Ratio and Inventory Time
100%
A
-
90%
A
A
-
-
60%
-
o50%
&
40%
-
20%
--
30%
ag~--
-
----
-__
--
-
_
--
__
-
-
10%
-
0
20
40
60
80
100
Inventory Time [Eng. Days]
Figure A-9 Changes in Rework Ratio with Time (Project A)
170
5. CONCLUSION
Overall
" The lean tools and processes developed in this research have proved to be able to
identify problems both peculiar and common to the organizations.
" Therefore, these lean tools and processes can deliver to product development
organizations information that leads to continuous improvement of their value-creating
processes.
Nine Waste Indicators
* The nine waste indicators were sufficient for identifying and measuring waste in product
development processes.
* Among the nine waste indicators, three waste indicators, over processing, rework, and
defective information were more significant than the others, implying the possibility of
reducing the number of waste indicators.
Rework
N It has been shown that time per one occurrence of rework exponentially increases as
time spent on the project increases.
Inventory of Information
"
"
Inventory of information was prevalent in product development processes.
Analysis of inventory of information has revealed that the development processes of
the investigated projects have turned out more or less similar to the unsynchronized
"
manufacturing processes several decades ago.
In one of the investigated projects, information got rotten at the rate of 6% a month.
This indicates information inventoried for a month causes additional engineering work
by 6%.
Root-Cause Analysis Diagram
E The root-cause analysis diagram was useful for identifying typical root-causes for waste.
Value Stream Mapping for Quantitative Analysis
N Value Stream Mapping Optimized for Quantitative Analysis was applicable for
measuring waste using the waste indicators.
171
(C
APPENDIX II ROOT-CAUSE ANALYSIS DIAGRAM
Root-Cause
1. OVERPRODUCTION
PD's Nature(1)
Impossibility of
Complete Elimination of Risks/
Uncertainties is Impossible
completely clear 4
division of labor
Unclear division
of labor
Scattered Locations
1.
Overproduction
Inaiit somPrompt
Division of Labor
+-
Tafrdyio
Transfer
SpatialStructual
__ Complex Organizational
Structure
Outsourcing
Functional Organization
Complex Hierarchy
Structure of Organization
Patch Work
(Adding Features that was not
considered when the
architecture was designed
Making use of Legacy _
Sources
Incremental PD:
Making Use of the
Architecture of Previous
Model
I
Too Complex Design
Poor Interface Design
Premature Architecture
Design
_
I
173
Redundancy of
Functions in
Company
I
De-Centralized
Organization
Organizational Structure
Unoptimized for the
Product
174
Root-Cause
2. WAITING
Scheduled Waiting
(Waiting Time is +
within Scheduled
Buffer/Slack Time)
Limited Resources(2)
Originally
Unsynchronized 44
Schedule
I
Excessively Lon
Buffer Time
(Over Statistical
Fluctuation)
-
__
Limited Qualification of
Designers
inadequate Scheduling
Technique
Nature of PD(4)
Statistical Fluctuation
Engineer' s Neglect
of Schedule
EfLack of Strong
9
Enforcement of Schedule
(Or Effective Incentive)
Waiting for
Handing off of
Information
Limited Resources(1)
System Over Utilization
(Unrealistic Schedule)
Too Tight
(Unrealistic)
- Schedule
4Highly
Competitive
Market
Scheduled, but
Longer Than
Scheduled
Time-Sensitive Product
Schedule
Inadequate Scheduling
Skills
9.Defective Information
2.Walting
(People are
Unidentified
Risks/Uncertainties
Waiting)
Concurrent
Expediting
175
Engineering(1)
-- (Designers Get Involved .
in Production' s/User' sTrva
t
Problem)
Critical Design
usos
O h r
Issues
Unscheduled
Waiting
Limited Resources(1)
System Over Utilization
(Unrealistic Schedule)_J
Fatigue
Poor Resource Allocation
Suitable
Designer' s
Temporal
Unavailability
Local
Level Scheduling
OverNo
Utilization
Limited Resources(2)
Limited Qualification of
Designers
Limited Resources(2)
Limited Qualification of
Designers
No Replacement
Tardy Approval
Inside of the
Organization
Waiting forOusrcn
Validation of 4-_
Outside
of the
3.Transportation
Waiting for
(Designers Get Involved
Production' s/User'
Problem)
Inquiry
Trivial
Questions
Specific Area
Organization
3.Transportation
Waiting for
Info.Processed
INSIDE of the
Failing to send
Inquiry in Advance
Organization
Critical Design Issues
in
Entering into the
Completed
Information
Go to "3.Transportation"
Lack of Accumulated
Waiting for
--
-
Engineering(1)
Idea of DFM
(Downstream Tasks'
Commitment to
Upstream Tasks)
Infrmaio
OranzatonData/Expertise Inthe .4Market
Answers for
-
176
f
New to The
Go to
"3.Transportation"
Unplanned
Communication
Inadequate Scheduling
Technique
Nature of PD(3)
Identifying All
Interfaces In Advance
is Impossible
-
Waiting for
Info.Processed +
OUTSIDE of the
Organization
Limited Resources(5)
System Over Utilization
On The Organization
Level
Answer Delayed
Entering into the
Market New to the
Organization
Lack of Accumulated
Date/Expertise in the +
Specific Area
Dispersed
Information w/o
Maintained Index
Easiness to Get More
Structured Information
from Outside Than
Doing Information
Hunting In the
Organization
(PaperElectronic)
Difficulty to Find
the Right Person
Poor Knowledge
Management
Difficulty to Reach
the Right Person
Waiting for
Information
Processed by
Hardware
Obsolete Hardware
*
Nature of the Task
Existence of
-Inter-
Complex Product
Architecture with
Excessive Interfaces
.4
1PD's Nature(2)
Iteration cannot be
Dependency
Eliminated
Waiting for
from
Mutually
W=
Dependent
Tasks
I
Engineer' s
Neglect of
Schedule
Information
177
Lack of Strong
Enforcement of
schedule
(Or Effective
Incentive)
Reuse of General
Schedule Not
Optimized for the
Current Project
No Leveled
Scheduling
Too Tight
(Unrealistic)
Schedule
L
-
Delay in
Mutually
-
Limited
Resources(1)
System Over
Utilization
(Urealistic Schesule)
Highly Competitive
Market
Dependent
Tasks
Time-Sensitive
Product
Way-Off
Schedule
4
Inadequate
Acheduling
9.Defective
Information
-
Happenings
Unidentified
Risks/Uncertainties
Limited
Resources(7)
Limited Tools /
-
Prototypes /
Hardware
Waiting for
Tool/Material/
Hardware/Software
Insufficient
Maintenance of
Development
Environment
178
3. TRANSPORTATION
Root-Cause
There' s No Perfect Suite
Tranporatio Use f Nn-EProduct MaualHanding
Trnforation
of
M-ao nformationg
Uscuments
4
itself
Imperfect
Compatibility of
Different
Adopting Applications
From Different
Software Companies
,_Legacy
Platforms/Software
3
Transportation
of Information
Difference from
Suppliers' Platforms
Software Industry' s
Dynamic Condition
from Past
Developments
Outsoucing
Frequent Version-Ups
4
Changes in Documenting
/Database Format /
Guidelines
-reformatting
Td
Changes in Design
Methodology
Complex Organizational
Structure
Scattering Locations
-E1Outsourcing
Spatial/Structural Barrier
Complex Hierarchy
Structure of Organization
Functional Organization
179
Lack or Lack of strict
Enforcement of
Inside the Organization
Reading/Replying Rules
-o
No Suitable Communication
Tool for the Specific
Purpose
No Sure/Reliable
Communication Channel
Outside of the Organization
Having no direct business
relation (e.g. supplier and
user)
4
Complex Organizational
Structure
Expertise needs to be
shared among remote
locations
Spatial/Structural Barrier
Scattering Locations
Outsourcing
Complex Hierarchy
Structure of Organization
Functional Organization
Education / Training
Using New Engineers
F
New area to the engineer
Complex Organizational
Structure
Scattering Locations
Outsourcing
Tardy Approval
Process
I
Spatial/Structural Barrier
i
Complex Hierarchy
Structure of Organization
Functional Organization
180
Root-Cause
4 OVER PROCESSING
Individual Designer' s
Poor Understanding
of Downstream
Tasks
(e.g. Manufacturing)
Lack of Constructive
Advice from
Experienced
Designers
Limited
Resources(2)
Limited Qualifications
of Designers
4
Lack of
Experienced
Designers
Limited
Resources(1)
ANo Time
org
System Over
Utilization
Insufficient Time
No Level Scheduling
Local Over
Utilization
Limited
Resources(2)
Limited Qualifications
of Designers
Complex
Organizational
Spatial/Structural
Barrier
Structure
fusurcing
Corporate Culture
Specifying Too
Musch Detail
Complex
Organizational
Structure
4
Complex Hierarchy
Structure
SaSpatial/Structuralt
4.Over
Processing
BarrierSatrngotis
Functional
Organization
181
Doneam'
.Mnuacurng
Commitment to
Design
No Time
Available for
Interaction with
Downstream
(Manufacturing)
Limited
Resources(1)
System Over
Utilization
Insufficient Tim~e
Local Over
Utilization
No Level Scheduling
Limited
Resources(2)
Limited Qualifications
of Designer
Limited
Resources(1)
System Over
Utilization
Insufficient Tim:
No Level Scheduling
Setting Too
Local Over
Utilization
There' s No Time for
Optimization
Small
Limited
Resources(2)
Limited Qualifications
of Designers
Tolerances
Lack of
Empirical
Knowledge
Poor Buffer
-A
-
Designing
Features That is
Not Specified by
Specification
(Different from
Spec.)
Slack(Or Buffer)
Time
Becomes
Self-Fulfilling
Prophesy
Allocation
Limited
4Resources(2)
Limited Qualifications
of Designers
Distribution of
BufferskEve
Poor Schedule/
Progress Control
Impractical Incentive/
Measurement
No Incentive for
Propesy
arlyFinih
4System
Highly Competitive
Market
B to C
Instability of
182
Market
Exogenous
Factors
Customer' s Poor
- Understanding of the
FMarket
-B
Unclear/
Shifting Goal
to B
Highly Competitive
Market
Existence of
Uncertainty
Culnconsistency in
Customer' s Decision
Endogenous
Factors
Lack
Complexity of
the Product
of Modularity
Nature of the Product
Risk-Taking Strategy
Low TRL
Poor Understanding
of Current
Technology
Inadequate
D eve opme'nIt T im e
Underbid
Inadequate
Decision
Process
Tardy Decision
Prces
F
Inadequate
-
Underestimation
-of Development
Cost
183
Scheduling
Technique
Technological
Uncertainty
_Lack
of Feedbk
Poor Marketing
Inadequate
Marketing Method
Lack oFDFM
Lack of
--- Feedback Loop
Lack of Concurrent
Engineering
Waterfall Process
without Proper
Prototyping
Limited
Resources(1)
Insufficient
Time
to Read/
-Examine/
Release
System Over
Utilization
fnsufficient Time
Information
No Level Scheduling
Local Over
Utilization
Insufficient
Pervasion of
Goal Information
Limited
-Resources(2)
Limited Qualifications
of Designers
Complex
Organizational
Structure
Scattering Location
Outsourcing
Spatial/Structural
Barrier
Complex Hierarchy
Structure of
Organization
Functional
Organization
184
]
Lack of
Measurement of
U
esines
UfGo
co u
Designer' s
Achievements in
Terms of Goal
Perfectionist
s
Personality of
Engineer
Complex
Organizational
Structure
-Scattering Locations
Tardy
-
Information
Spatial/Structural
Barrier
Outsourcing
usrcn
Transfer
Complex Hierarchy
Structure of
Poor Availability
of Necessary
-Organization
-4----_Ognzt
Info.
Functional
Organization
Tardy
-Information
Transfer
Imperfect Human
Relationship
PD's Nature(2)
Iteration cannot be
Optimization
Process
Interface
Redesign
eliminated
eiiae
PD's Nature(3)
Identifying All Interfaces
In Advance is Impossible
Changes
Poor Marketing
Poor Information Quality
from Upstream Phases
Information
Premature Concept
Design
Premature Architecture
Design
185
Poorly
manufactured
1
Prototype
Late /Lack
- Verification
Process
Undiscovered
Unreliable/
Upstream Task's
Dependency on
Downstream Tasks
for Verification(E.G.
Manufacturability)
Verification by
Independent
Errors in
Outputs from
Upstream
Working on
Veniication
Performed by
Downstream
Tasks
Process
Existence Of
Uncirtaintles/R4sks
(Teaing,etc.)
+
Defective Info.
9. Defective
Information
Verified by
Extemal
Organization/
People
Limited
Resources(3)
Limited Capability of
Organization
Limited
Resources(1)
Concurrent Engineering(2)
Overlapping
Schedule
System
Information Pulled Before
Validation and/or Optimization
of Design Parameter Sets
Over
Utilization
(Unrealistic
Schedule)
Highly Competitive Market
Too Much Concurrency
(Complex product or LowTRL)
--
Prototype
Version
Poor
rk-in-Process Version
Confusion
Management
Insufficient/ No
Communication
-_
Scattered
Spatial
Barrier
Locations
Complex
---
Organizational
Structure
Outsourcing
-Functional
Organization
Complex Hierarchy
Structure of Organization
186
J
Being Forced to Use NonIdeal Tools /Prototypes/
Hardware
Limited
Resources(7)
Limited Tools!
Prototypes I
Hardware
4
There' s No Perfect
Suite Product
Manual Data
Conversion
(E.G.
Peformatting)
Adopting
Applications From
Different Software
Companies
Imperfect
Compatibility of
Different
Platforms/Software
Software Industry' s
Dynamic Condition
Legacy Data from
Past Developments
Difference from
Suppliers'
Platforms
Outsourcing
+-
Frequent
Version-Ups
Defective
information found
in handed-off
information
10.Defectlve
Information
Incomplete
concept
development
Needed
information was
not identified in
Creating a
workaround
solution
Needed
L information not
available
+-
.Needed
-
information
was to be fed
187
TRL
-Low
project planning
Delay in
upstream
pcsss
Unsynchronized
proes
ross
Originally
unsynchroniQed
Unoptimizd
_ [scheduling technique
10epouto
Unsynchronized
because of waste
in UPStream1
proceIsses
2.aiin
-3.Transportation
Being Forced to Use NonIdeal Tools /Prototypes/
Hardware
Limited
Resources(7)
Limited Tools/
Prototypes /
Hardware
4
There'
s
No Perfect
Suite Product
Manual Data
Conversion
(E.G.
Peformatting)
Imperfect
Compatibility of
Different
Platforms/Software
Adopting
Applications From
Different Software
Companies
Software Industry' a
Dynamic Condition
Legacy Data from
Past Developments
Difference from
Suppliers'
Platforms
Outsourcing
Frequent
Version-Ups
Defective
Information found
in handed-off
Information
9.Defective
Information
Creating a
workaround
solution
information wasdvlpmn
~not
Incomplete concept
Neededdevelopment
Identified In
project planningTRL
Originally
Needed
information not
unsynchronizIe~d*_
avaiabl 1
. Needed
-
information
was to be fed
188
Delay In
upstream
iprocesses
Unsynchronized
o
prbes
..
nsynchronized
bcause Af waste
in upstream
processes
UnoptImIzd
schedulIng technique
vrrouto
2.+tn
-3.Transportation
5. Motion
6. Rework
7. Re-invention
8. Hand-Off.
9. Defective
Information
Design
technique/
philosophy not
consistent with
the
organization' s
way
Creating Needless
Information
Lack of basic
training
Lack of documentation of
structured design rules
Scattered
Locations
Spatial
Barrier
Complex
Organizational
Structure
4-
Outsourcing
In icnt No
Communication
-
-
Functional
Organization
Complex Hierarchy
Structure of Organization
Schedule
Pressure
4--
Too Tight
(Unrealistic)
4
Limited Resources (1)
System Over Utilization
Highly Competitive
Market
Time-Sensitive Product
WaySchedule
Strategically
Processing
Multiple
Solutions
189
Intention
to
Reduce Risk,
InadequateScheduling
Technique
Existence of Risks/
Uncertainties
5 MOTION
Root-Cause
Knowledge is NOT
Inside of
Information
No experience in the area
4
Organization
Hunting
Knowledge
-
--
is Inside
Dispersed
(Now Field to the
Information
Organization)
w/o Maintained
lndex(Paper,Electronic)
of he rgaizaionDifficulty
to find the
Poor Knowledge
Management
Right Person
Difficulty to Reach the
Right Person
5.Motion
+-
---
Need to Leam
from Basic
Knowledge
Using New Engineers
Inexperience of
engineer o
-
New area to the engineer
Critical Design isues
Overuse of Designers
- (Should be done by other
Concurrent Engineering(1)
(Designers Get Involved in
Production' s/User' s Problem)
-
engineers)
Others
Stop-and-Go
Tasks
Suitable
Designer'
Limited Resources(1)
System Over Utillization
(Unrealistic Schedule)
s 4-
Unmpoal
--
- - -
Fatigue
_-Poor Resource
Allocation
UnavailbilityLocal
Over
Utillization
No Level Scheduling
Limited Resources(2)
Limited Qualification of
Designers
Limited Resources(2)
Limited Qualification of
Designers
No Replacement
Testi / QCDefective
g/
190
QCOutsourcing
Information
Desire to Save
Information Releaser' s
Time
Meeting Just for
Information Sharing
Intensive
Interaction' sHelpfulness
for Creating
Ideas/Problem
Solving/DR
Meeting for Value
Meetings
-
-
Creation/Problem
+
Solving/Design Review
Narrow Bandwidth of
Existing
Network(Resulting inLow
Limited Capability of
Tele-Conference
--------
--
Business Trip
+ -
Resolution,Late
4
Response)
Preture ITTechnology
-
Complex Organizational
Structure
Spatial Barrier
Scattering locations
Spend Time on Learning
How to Use Support
4
-
Equipments
Spend Time on Complex
Operation of support
Outrring
Complexity of Support
Equipments
4
Equipments
Required Activity
3.Transportation
--
Supporting
Outsourcees 4
Outsourcing
191
Root-Cause
6 REWORK
PD's Nature(2)
Iteration cannot be
eliminated
Interface
Optimization
Process
Redesign
PD's Nature(3)
Identifying All Interfaces
In Advance is Impossible
Upstream
Poor Marketing
Information
Poor Information Quality
from Upstream Phases
Premature Concept
Design
Premature Architecture
Design
9.D3efective
Information
Impossibility of completely clear
diviionof
PD' s Nature(1)
Complete Elimination of
lborRisks/
Uncertainties is
Impossible
Unclear division
-
Scattered Locations
Complex Organizational
-Structure
Unplanned
Iteration
Inability of Prompt
Adjustment of +
Division of Labor
Tardy
Information
Transfer
Spatial/Structual
Barrier
Outsourcing
Functional Organization
6. Rework
Complex Hierarchy
Structure of Organization
Prototype
Version
Confusion
Poor
Work-in-Process Version
Management
192
Scattered
Insufficient/
No
Communication
Creation of Low
Quality
Information
SpatialLctin
Barrier
Complex
Organizational
Structure
Outsourcing
Functional Organization
Complex Hierarchy
Structure of Organization
Schedule
Pressure
Too Tight
(Unrealistic)
Schedule
Limited Resoumes (1)
System Over Utilization
Highly Competitive
Market
Way-Off
Schedule
Inadequate
Scheduling
Technique
Insufficient
Training
oTimesinerdc
Qualification
Pna
sllroc
Limited Resources (2)
Limited Qualification
of Designers
Troubleshooing /:Dagnosis
Working on Unreliable/
Defective Informationt
_on
9. Defective
Information
Go to
"9. Defective
Information"
193
J
Leaving
Uncertainties
/Risks
PD's Nature()
Complete Elimination of
-Risks/
Uncertainties is
Failure to
Identify
4--
Risks/
Uncertainties
Intact
4
Early
Impossible
Lack of Risk
Management
Risks
Alarm
Identified
Suppressed
High-level
Unrealistic
Late al
n Schedule
couldBouned
Highly-Competitive
(Market
-Time-Sensitive
Product
Rik-ThkenMssregey
Limited Resources (1)
System Over Utilization
Validation
could
have been
Possible
Bounded
Rationality
Corporate Culture(3)
to
-Reluctance
.Accept Bad News
Kill The Messenger"
4
-Rs-aigSrtg
Premature Vaiato
Poor Risk Management
Poor Risk Management]
Alarm NOT
Suppressed
Inappropriate/
Late Valiation
Lack of Solid Strategy
(Tactics Only)
Premature Validatin
Skill
194
Iteration Among
Remote Tasks
Needs long time to get feedback
Wasteful
Planned
Iteration
ScOpizeNot
Iteration
4---
Lack of
.4
Between
Adjacent Tasks
Iteration Among
"Kento(chedking)"
Before Action
Slow
Interaction
Parallel Tasks
Insufficient/ No
Communication
Scattered
Locations
Spat ial
Barrier
Complex
Organizational
Structure
Quick iteration: no or minimum
waiting time for feedback
Outsourcing
Functional Organization
Complex Hierarchy
Structure of Organization
Too Tight
Schedule
(Unrealistic)
+
Pressure
PressureSchedule
4
Limited Resources (1)
System Over Utilization
Highly Competitive
Market
Time-Sensitive Product
Way-Off
Schedule
195
Technique
Complex Product
Architecture
With Excessive Interfaces
Benign or Good
PD's Nature(2)
Iteration cannot be
eliminated
196
7. RE-INVENTION
Root-Cause
_Poor Expertise
Sharing
No system for Expertise Sharing
Temporal Barrier
Existing System for Expertise
Sharing not Useful
I
-Takes Long Time for Inputting
7. Re-invention +---
-Takes Long Time for Seaching
Project Organization
(As opposed to Functional
Organization)
I
Spatial/Structura
I Barrier
Scattered Locations
(Distributed Team)
I
Complex Organizational Structure
(Redundant Functions)
I
Contextual
Barrier
*-
Outsourcing
Confidentiality of Expertise
Corporate Culture(1)
Designer's Try to Protect Their
Value By NOT Sharing Their
Expertise
Designers'
Unwillingness to Share
Their Expertise
Lack of Appropriate
Incentive/Measurement System
that Promotes Expertise Sharing
I
197
I
Root-Cause
8. HAND-OFF
Dissemination
Requirements
of
Complex Product Design
-Scheduled
Hand-Off +-+-Time-Sensitive Product
--- Sharingt+--8. Hand-Off
oWork
4
-Intention to Level Workload
I
Unscheduled HandOff
Outsourcing
Unloading Tasks
on the Critical
Path
PD's Nature(1)
Complete Elimination of
Risks/Uncertainties is
Switching to an
expert
Limited Resources (2)
Limited Qualifications of
Designers
Impossible
Absence of Task
Owner
198
9. DEFECTIVE INFORAMTION
Root-Cause
No System for Knowledge Sharing
Temporal Barrier
Useless System for Knowledge
Sharing
-Takes Long Time for Inputting
-Takes Long Time for Searching
Scattered (Distributed) Locations
Information
With
Errors
Predictable
Errors
Poor
Knowledge
Sharing
Spatial/
Structural
Barrier
Project Organization
(As opposed to Functional Org.)
-4
Complex Organizational
Structure
(Redundant Functions)
-H
Contextual
Outsourcing
Confidentiality of Knowledge
Barrier
Corporate Culture(2)
Failure are Likely To
Designers'
Unwillingness
to Share Their
be Blamed on Individuals
Failure
Lack of Appropriate
Information
Incentive /Measurement
System that promotes
failure info. sharing
9. Defective
Information
Local Over
Utilization
Limited Resources(1)
System Over Utilization
(Unrealistic Schedule)
Poor Resource
Allocation
No Level Scheduling
Too Many_________
Lapses
Undetected
Errors
199
Limited Resources (2)
Limited Qualification
of Designers
I
I
Poor Resource
Allocation
Limited Resources (2)
Limited Qualification of
Designers
Primitive
___
_
Errors
Limited Resources (3)
Designers' Limited
Experience in Similar
Projects
Poor Resource
Allocation
No System for Design
Review (DR)
By Experienced
Designers
No Effective
Limited Resources(1)
Error Checking
System Over Utilization
- No Leveled Scheduling
Utilization
Limited Resources (2)
Limited Qualification of
Designers
Alarm
Bounded
Corporate Culture(3)
Reluctance to
Accept Bad News
Suppressed
Rationality
"Kill The Messenger"
-
Risk-Taking Strategy
Poor Risk Management
200
Highly Competitive
Market
High-level
UnrealisticsitiveProduct
Schedule
Pressure
SceueLimited
BPSchcdut
Resources (1)
System
Over Utilization
Incremental
--
Unpredictable
ErrorsP
Product
Development
'ects Taken
ver from
ious Models
--
WPD's Nature()
Complete Elimination
of Risks/
Uncertainties is
Impossible
er
Temrl Barri
Sequential PD Process
Withoutinteractions
Information
Deteriorated
-~
Batch Production
Through
Complex Hierarchy
Structure of
Organization
Communication
Complex
Organizational
Spatial/
Structural
Barrier
Structure
(Redundant Functions)
4
Functional
Organization
Scattered (Dispersed)
Locations
-Outsourcing
Contextual
Barrier
201
Confidentiality of
Knowledge
(BtoB)
Complex Product
Architecture with
Excessive Interfaces
Lack of Modularity
Complexity of
incomplete
Information
"UnderProcessing"
Information not
really complete
h
rdc
Information
Wrongly
Perceived to
be Complete
4
Nature of the Product
-
I
Lack of
Necessary
Expertise
Inexperience
in the
business
Low Morale
Inappropriate/
- Insufficient/
Late Validation
e
-----
Engineers
Neglect
of Perfection
4
Lack of Incentive
Corporate Culture
Risk-Takings
Limited Resources
(all)
Budget/ Expertise/
Qualification/ Facility
PID's Nature(1)
Complete Elimination
of Risks/
Uncertainties is
Impossible
Poor Risk Management
Lack of Solid Strategy
(Tactics Only)
Premature Validation
Skill
ightHighly
Too
Too
ightMarket
(Unrealistic)
Schedule
202
Competitive
4-
H
Time-Sensitive Product
Predure
-
Limited Resources(1)
Over Utilization
(Unrealistic Schedule)
_System
Pressure
Not Optimum
Schedule
Inadequate Scheduling
Technique
No System for
Expertise Sharing
Comm
ication +
TmprBr
Existing System for
Expertise Sharing not
Useful
-Takes Long Time for
Inputting
-Takes Long Time for
Searching
Project Organization
(As opposed to
Functional
Organization)
Spatial/
Structural
Scattered Locations
(Distributed Team)
Barrier
Complex
Organizational
Structure
(Redundant Functions)
outsourcing
Contextual
Barrier
203
Confidentiality of
Expertise
]
Limited Resources(1)
System Over Utilization
(Unrealistic Schedule)
Highly Competitive
Market
Mre
Concurrent Engineering (2)
Information Pulled
Overlapping
f-Tof Tasks
Releasing of
Tentative
BeforeOptimization
Validation and/or
-
oToo
-
Information
Delay
Inthe task
itselfTask
Delay in the
upstream tasks
204
Waste In Current
Waste
In Upstream
Task
much concurrency
(complex product or
low-TRL)
BIBLIOGRAPHY
1.
Allen, Thomas J. (1984), "Managing the Flow of Technology: Technology Transfer and the
Dissemination of Technological Information within the R&D Organization," The MIT Press,
Cambridge, MA.
2.
Bauch, Christoph (2004), "Lean Product Development: Making Waste Trasparent," Diploma
Thesis, Massachusetts Institute of Technology and Technical University of Munich.
3.
Brooks, Frederick P. (1975), "The Mythical Man-Month," Addison-Wesley Pub. Co, Reading,
4.
C.M. Creveling, J.L. Slutsky and D. Antis, Jr. (2000), "Design for Six Sigma in Technology and
Product Development," Prentice Hall PTR, Upper Saddle River, N.J.
5.
Fleisher, Mitchell and Jeffrey Liker (1997), "Concurrent Engineering Effectiveness : Integrating
Product Development across Organizations," Hanser Gardner Publications, Cincinnati.
6.
Forsberg,
Kevin,
Hal
Mooz,
and
Howard
Cotterman
(1996),
"Visualizing
Project
Management," John Wiley & Sons, Inc.
7.
Graebsch, Martin (2005), "Information and Communication in Lean Product Development,"
Diploma Thesis, Massachusetts Institute of Technology and Technical University of Munich.
8.
Goldratt, Eliyahu M. and Jeff Cox (1984), "The Goal," The North River Press, Great Barrington,
MA.
9.
Goldratt, Eliyahu M. (1997), "Critical Chain," The North River Press, Great Barrington, MA.
10. Kaplan, Robert S. and David P. Norton (1992), "The Balanced Scorecard - Measures that Drive
Performance" Harvard Business Review, Jan-Feb 1992, Cambridge, MA.
11. Kruchten, Philippe (1999), "The Rational Unified Process," Addison-Wesley, Reading, MA.
12. Lyneis, James (1999), "System Dynamics for Market Forecasting and Structural Analysis,"
System Dynamics Review, Vol. 15-1, 2000
13. Lyneis, James (2000), "System Dynamics for Business Strategy: A Phased Approach," System
Dynamics Review, Vol. 16-1, 2000
14. McManus, Hugh(2004), "Product Development Value Stream Mapping Manual, Beta Version,"
Lean Aerospace Initiative, MIT, Cambridge MA
15. Morgan, James M. (2002), High Performance Product Development: A Systems Approach to a
Lean Product Development Process," PhD. Thesis in Industrial and Operations Engineering,
The University of Michigan.
16. Murman, Earll, Thomas Allen, Kirkor Bozdogan, Joel Cutcher-Gershenfeld, Hugh McManus,
Deborah Nightingale, Eric Rebentisch, Tom Shields, Fred Stahl, Myles Walton, Joyce
205
Warmkessel, Stanley Weiss, and Sheila Widnall (2002), "Lean enterprise value : insights from
MIT's Lean Aerospace Initiative" Palgrave, New York
17. Ohno,
Taiichi
(1978),
"Toyota
Production
System:
Beyond Large-Scale
Production,"
Productivity Press, Cambridge, MA.
18. Oppenheim, Bohdan W. (2004) "Lean Product Development Flow," System Engineering, Vol.
7-4, 2004.
19. Pich, Michael T., Christiph H. Loch, and Arnoud De Meyer (2002), "On Uncertainty,
Ambiguity and Complexity in Project Management," Management Science, Vol. 48-8, 2002.
20. Repenning, Nelson P. (2001), "Understanding Fire Fighting in New Product Development," The
Journal of Product Innovation Management, Vol. 18, 2001, pp. 285-300.
21. Shenhar Aaron J, Dov Dvir, Thomas Lechler, and Michael Poli (2003), "One Size Does Not Fit
All"
22. Slack, Robert A. (1999), "The Application of Lean Principles to the Military aerospace Product
Development Process," Master's Thesis in Engineering and Management, MIT, Cambridge,
MA.
23. Soderloud, Jonas (2002), "Managing Complex development Projects: Arenas, Knowledge
Processes and Time," R&D Management, Vol. 32-5, 2002.
24. Sterman, John D. (2000), "Business Dynamics" McGraw-Hill Higher Edication.
25. Stewart, Wendy E (2001)., "Balanced Scorecard for Projects," Project Management Journal,
March, 2001.
26. Ward, Allen, Jeffrey K. Liker, John J. Christiano, and Sobek II, Durward K. (1995), "The
Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster," Sloan
Management Review, Spring 1995, Cambridge, MA.
27. White, Diana and Joyce Fortune (2002), "Current practice in project management -- an
empirical study," International Journal of Project Management, Vo. 20, 2002.
28. Womack, James P. and Daniel T. Jones, and Daniel Roos (1991), The Machine That Changed
the World," Harper Perennial.
29. Womack, James P. and Daniel T. Jones (1996), "Lean Thinking," Simon & Schuster.
206