# Lean Product Development: Serious Game and Evaluation of the Learning Outcomes

Endris Kerga, Armin Akaberi, Marco Tasich, Monica Rossi, Sergio Terzi

► To cite this version:

Endris Kerga, Armin Akaberi, Marco Tasich, Monica Rossi, Sergio Terzi. Lean Product Development: Serious Game and Evaluation of the Learning Outcomes. 19th Advances in Production Management Systems (APMS), Sep 2012, Rhodes, Greece. pp.590-597, 10.1007/978-3-642-40352-1_74. hal-01472297

HAL Id: hal-01472297

https://inria.hal.science/hal-01472297

Submitted on 20 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Lean Product Development: Serious Game and
Evaluation of the Learning Outcomes

¹Endris Kerga, ¹Armin Akaberi, ¹Marco Tasich, ¹Monica Rossi, ²Sergio Terzi,

¹Politecnico di Milano, Department of Economics, Management and Industrial Engineering,
Piazza Leonardo da Vinci 32, Milano, 20133, Italy

endris.kerga@mail.polimi.it, armin.akaberi@mail.polimi.it,

marco.taisch@polimi.it, monica.rossi@polimi.it

²Università degli Studi di Bergamo, Department of Industrial Engineering Viale Marconi 5,
Dalmine (BG) 24044, Italy

sergio.terzi@unibg.it

**Abstract.** This paper presents a Serious Game (SG) about SBCE (Set-Based Concurrent Engineering), which is one element of Lean thinking in Product Development (PD). The game is structured in two stages that simulate the traditional approach to product concept development called PBCE (Pont-Based Concurrent Engineering) and SBCE approaches. Moreover, this paper presents the learning outcomes gained through running the game in a company. Finally, some practical and theoretical insights gained throughout the game play are introduced.

**Keywords.** Lean Product Development, Set-Based Concurrent Engineering, Serious Game.

# 1 Introduction

Set Based Concurrent Engineering (SBCE) is an element of lean thinking in product development (PD). It is effective at early stages of design when concepts are generated and selected [1], [2]. In a traditional approach which is called Point Based Concurrent Engineering (PBCE), a single concept is selected as early as possible assuming that it will be feasible. However, PD is characterized by uncertainties due to changes in customer requirements, manufacturability issues, sub-system configurations and so on. Thus, often PD project suffers from design reworks due to the so called ‘false positive feasibility’, where project teams assume a concept is feasible, but will learn later in the development process that it is not [3]. Toyota uses SBCE approach to tackle such a problem by effectively utilizing product knowledge (lesson learned) to generate alternative design concepts. Unless a concept is proven to be infeasible, designers won’t eliminate it from a solution set. The unique feature in SBCE process is that design decision is based on proven data. Communication and negotiation within teams are facilitated by a pull event where teams can visualize risk and opportunities using tradeoff and limit-curves. Finally, PD teams converge into an optimal design
taking rough objective criteria (such as cost, quality and time), so as the process will continue to detail design stages [1], [2].

In practice, however, the awareness and the adoption levels of SBCE is limited across the industries surveyed [4]. Therefore, the purpose of this paper is to design and validate a learning tool using a serious game approach that enable practitioners to have a hand on experience about SBCE principles and its associated enablers.

In section 2, introduction to the game's features will be introduced. In section 3, a model to evaluate the learning outcomes of the game will be discussed. The results found in the one game play will be presented in section 4, and followed by conclusions in section 5.

## 2 Introduction of SBCE Game

To design the SBCE learning tool a serious game approach is used. In general, the application of games with the aim of education and learning is defined as “Serious games” [5]. In SG, players assume different roles and are involved in simple and complicated decision making processes, which makes it attractive for SBCE process where alternative design exploration and convergence involve multiple-views. Moreover, SG creates a safe and entertaining environment, so that players from the industry freely experiments SBCE process without interfering in an actual PD process.

In the game, players have to design a simplified Airplane structure as shown in Figure1, using different type of LEGO bricks. The Airplane has four sub-systems to be designed (body, wing, cockpit and tail). The game is divided into two stages: Stage one, where players design an Airplane for a given list of customer requirements following a PBCE process; Stage two, where players are provided with the necessary enablers to execute SBCE process. The enablers will help players to explore alternative design concepts, communicate about alternative solutions within a team, and converge into a preferred (a high value) Airplane structure. After each stages, players performances' breakdown in terms of cost and time of development will be provided to facilitate discussion. The game is played in a team of four players and each player represents sub-system departments (body, wing, cockpit and tail).

The main inputs to the Stage one of the game are: Customer requirements and supplier components catalogue. The list of customer requirements to build an airplane structure were made intentionally to be vague, for example, the number of passengers might be from 90 to 120 and the wing span could be 7 to 15. Such range of customer requirements (vague) reflect the reality, in which customers often suggest imprecise information, and force designers to explore their concept solutions wide open. In the game, these requirements can be handled in different ways in the Stage one (PBCE process) and in Stage two (SBCE process). Thus, players will understand the advantage of following SBCE than PBCE process to better achieve the customer requirements. In the game, there are five customer requirements: number of passenger (Np), Airplane weight (W) (Airplane structure (Wa) and passengers weights (Wp)), Length of Airplane (L), Wing span (ws) and Tail Span (ts).
The supplier components are LEGO bricks in different sizes and shapes that are used to build body, wing, tail and cockpit. Each brick has circular points on the top, and the number of points on the top of a brick define the characteristics of the component. A single point on a brick has the following character: Cost (10), Lead time or component ordering time (0.5), Capacity (3), Weight (100), Length (1), and Width (1).

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** A simplified airplane to be designed in the game (using LEGO bricks). "L": Length of Airplane, "lw": Length of Wing, "lb": Length of Body, "wb": Width of Body, "lc": Length of Cockpit, "Ws": Wing Span, "lt": Length of Tail, "ts": Tail Span</figcaption></figure>

## 2.1 Stage one and testing

Taking the customer requirements and the supplier catalogues, players will be asked to build an airplane in this stage. This stage simulates PBCE where players first design an airplane structure, build it and then test it to the constraints. *Design-Build-Test* approach is what many non-lean organizations follow at early stage of design [8]. Once players finish designing and building a prototype design in the first stage, they should submit it to “testing department” to check for stability, flying conditions and dimensional configurations as seen in Table 1.

<table><caption>**Table 1.** Testing constraints</caption><tr><td>Length – Wing span</td><td><sup>2</sup>&frasl;<sub>3</sub>L = &lt; ws &lt; L</td></tr></table>
<table><tr><td>Ratio of weight (RW)</td><td>R<sub>w</sub>=<sup>W<sub>p</sub></sup>/<sub>W<sub>a</sub></sub>&lt;1.25</td></tr><tr><td colspan="2">Wa = weights of all airplane components or structure</td></tr><tr><td colspan="2">W<sub>p</sub> = NP * 60 (Average weight of each passenger)</td></tr><tr><td>Airplane stability</td><td>lt&lt;lw</td></tr><tr><td>Alignment between body and cockpit</td><td>lc=wb</td></tr></table>

The facilitator of the game acts as a testing department. Players will not be given these testing constraints at the start of the game. If the design fails, the prototype should be redesigned. Redesigning has penalty costs and additional time to be penalized. After the first trial the testing constraints will be given to player. If the prototype passes the testing constraints, players will be given the breakdown of their performances in terms of cost and time. The determination of cost and time is executed as follows:

## Total development cost (C)

$$C=\text{cost of components (cc)}+\text{cost of iteration (ci)}+\text{cost of penalty (cp)}$$

Where, cc=Total number of points*single point cost, ci=30% of cost of components (this is an additional cost if players fail to pass testing constraints), and cp (is an additional cost if players fail to meet customer requirements). cp is determined based on unsatisfied customer requirements following the following rules:

<table><thead><tr><th>Unsatisfied customer requirement</th><th>Np</th><th>L</th><th>ws</th><th>ts</th><th>W</th></tr></thead><tbody><tr><td>cp</td><td>30%*cc</td><td>40%*cc</td><td>10%*cc</td><td>5%*cc</td><td>20%*cc</td></tr></tbody></table>

## Total development time (T)

$$T=\text{Total ordering Time (tot)}+\text{Assembly Delivery Time (ADT)}+\text{Iteration Time (it)}$$

Where, tot=Total number of points*Lead time, it=30% of Lead Time, and ADT=ADTI*tot. ADTI (Assembly Delivery Time index) is a function of an airplane wing length. ADT variable represents the required time that is needed to assemble the Airplane structure. To determine the ADTI values the following rules are used:

<table><thead><tr><th>lw</th><th>3</th><th>4</th><th>6</th><th>7</th><th>8</th><th>9</th><th>&gt;10</th></tr></thead><tbody><tr><th>ADTI</th><td>0.8</td><td>0.7</td><td>0.6</td><td>0.5</td><td>0.4</td><td>0.3</td><td>0.2</td></tr></tbody></table>

## 2.2 Stage two and supporting enablers

In Stage two, players will follow a structured SBCE process phases. This stage simulates a different approach than the first. Here, players follow a Test-Design-Build approach, and design decisions are made as late as possible until feasibilities are proven. In summary, players will explore, communicate set design solutions, evaluate
feasibilities of set of solution and finally converge into a preferred one. The different phases of the Stage two are:

A. *Explore alternative set of designs:* at this phase, players will be supported by QFD (Quality Function Deployment) tool to explore alternative sub-system solutions and able to ingrate customer requirements into an Airplane parameters. QFD is a powerful tool in applying SBCE process, it helps designers to translate rough customer requirements into alternative sub-system solutions [9]. Therefore, each player in a team will explore alternative body, wing, cockpit and tail solutions using its own QFD. This phase is the beginning of a SBCE process in the game.

B. *Communicating set of design solutions:* players at this phase can eliminate Airplane's sub-system solutions that are not compatible. For example, body department might explore alternative feasible body lengths as (11, 12, 14). Meanwhile, cockpit department might generate feasible body of lengths as (12, 13, 14). Therefore, the departments should eliminate incompatible body lengths (11 and 13).

C. *Provision of knowledge from testing department:* from step B, players have complete alternative Airplane solutions which are compatible, but need to filter them using physical constraints. In the game, physical constraints come only from the testing department. Limit-curves are used to generalize knowledge and visually depict solutions which are feasible from testing point of view, see [1, 2, 3] for more details about limit-curves. Therefore, at this phase, players eliminate those Airplane solutions which cannot pass the testing constrains listed in Table 1.

D. *Convergence to a preferred solution:* once alternative feasible Airplanes are identified, estimating the cost and development time of each Airplane solutions help to select the preferred solution. Refer section 2.1 to see the cost and time calculations used.

In summary, the second stage is to lead players through the step-wise phases of SBCE process. The objective is to educate players how to delay decisions early in design phase, and facilitate *test-design-build* approach to avoid unnecessary design reworks and missing customer goals.

# 3 Evaluation Framework for Learning Outcomes

The comparison of performances between the two stages can be taken as a validation mechanism to roughly estimate the advantages of SBCE process (Stage one) over the traditional process (Stage two). However, the main purpose is not to measure the performance leverages of SBCE process using the game. Because, the game is a simplified version of the reality and cannot capture the real complexities of a PD that make a SBCE approach more advantageous (such as product complexity, innovativeness of the product, team size and so on). Therefore, in this paper, it is aimed at measuring the effectiveness of the game to translate the SBCE principles and its associated supporting elements. Given that, it is also aimed at measuring how practitioners have perceived the potential of SBCE process and its elements in improving PD performances.
Garris et al. identified three level of knowledge aspects in order to measure the ef-
fectiveness of a SG[6]:

*   **Declarative knowledge:** is the learning of facts or increasing one's knowledge about a subject. In this paper, the understanding of the SBCE principles and its supporting enablers by players are parts of the declarative learning outcomes.

*   **Procedural knowledge:** this aspect refers to the learning of procedures, and also to the understanding of patterns of processes and behavior. In the SBCE game, procedural knowledge is related to players ability to associate the specific elements of SBCE process and the benefits of using them to support a better decision making.

*   **Strategic knowledge:** Within gaming this aspect has been explained as implementing knowledge from the game in a new (a real-world) situation. Gaming can also contribute to develop reflective competences. Within complex systems, as in PD, it is not only refers to implementing what is taught in the theory but also observing behavior and adapting to new situations. In SBCE game, several complexities have been simplified but adequate challenges are added to enable players to reflect beyond the gaming sessions into real world practices.

Based on the above framework, a structured questionnaire based on the Likert 5 scale has been prepared to measure the learning outcomes of the game. After playing the game with 36 designers (Mechanical, Electrical and Software) and project leaders of the Carel company (www.carel.com), players were asked to evaluate the declara-tive, procedural and strategic learning aspects of the game. The players have working experience ranging from 4-15 years and age from 25-50 years.

## 4 Results and Analysis

In general, the game has increased the level of awareness of players. Players under-
stand the usage of tradeoff and limit curves to generalize knowledge, and their appli-
cation in order to explore alternative designs. Communication among teams in SBCE
process takes different form than a traditional point based approach, where designers
have only once conceptual solution to communicate about. In traditional design ap-
proach, it is a norm that a functional team through ‘over the wall’ of a subsequent
function and vice-versa. In SBCE process, different functions pull together their con-
ceptual solutions and check sub-system compatibilities. In the game, players were
provided with simple check-list to support communication and negotiation among
teams. Though players understand how to use this communication mechanism, some
doubts are exhibited on the importance of using such a mechanism. This is due to the
simplicity of the Airplane to be designed, but in a real PD problem the complexity
grows as more functions have to communicate about the alternative set of solutions.

Figure 2 shows the perceived advantages of following a SBCE process from practi-
tioners perspective. The theoretical advantages of SBCE seems to be confirmed by the
practitioners. Most of the designers played the game agreed that the most significant
perceived advantages of SBCE are ‘facilitate learning about design solutions’ and
‘avoid design risks’. Using knowledge from past designs and exploration of alterna-
tive designs guarantee the PD teams to brainstorm about set of solutions rather than one alternative. Moreover, frontloading the PD process minimize the probability of ‘false positive feasibility’ to occur. The players perceived also that SBCE reduce the development time and cost. However, such claims cannot be guaranteed if teams are not able to identify when to stop exploring and start converging [7].

Among the main difficulties that have been mentioned to implement SBCE process is the generation of ‘limit-curves’. Limit curves are fundamental to apply SBCE process. They are curves that generalize knowledge of sub-system designs, and designers can see the ‘risky’ and ‘safer’ design regions.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** ‘Perceived performance’ improvements of SBCE process using the game (N=36)</figcaption></figure>

However, companies in the current practice don't use such curves to document, represent and share lesson learned or knowledge. Therefore, the main challenge will be to build the necessary competences to capture, represent and share past (static) and current (dynamic) knowledge gained through experimentation.

# 5 Conclusions

Most practical applications of SBCE process are reported from Automotive and Aerospace industries [1, 3, 10, 11]. In other industrial sectors its adoption level is limited.
There might be some elements of SBCE process in practice, but its implementation as a structured methodological approach in PD is not prevalent.

In this paper, a Serious Game that can bring a hand on experience is designed and the learning outcomes are measured taking a one company case. The company is in HVAC/R market (www.carel.com), which is different from Automotive and Aerospace industries. However, the players from different background and experience levels acknowledge that SBCE process is a much better approach than PBCE. Through the assessment, the players identified key advantages and hurdles of applying SBCE process in the company.

In summary, SBCE process is an attractive and sensible approach at early phase of PD compared to PBCE approach. However, companies need to have a structure practices, tools and technologies (enablers) to realize the process. Such enablers are supportive to explore alternative solution, enable set based communication and facilitate convergence to a high value solution.

## References

1. Sobek D.K., Ward A.C., Liker J.K.: Toyota's Principles of Set-Based Concurrent Engineering. Sloan Management Review, 40, 67-83 (1999)

2. Ward A., Liker J.K., Cristiano J.J., Sobek II D.K.: The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster. Sloan Management Review, 36, 43-61 (1995)

3. Oosterwal, D.P.: The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. American Management Association, New York, USA (2010)

4. Rossi, M., Kerga, E., Taisch, M., Terzi, S.: Lean Product Development: Fact Finding Research in Italy, International Conference on Industrial Engineering and systems Management (IESM) Proceedings, Metz (France)-May 25-27 (2011)

5. Wouters,P., van der Spek E.D. and Oostendorp H.: Measuring learning in serious games: a case study with structural assessment. Educational Technology Research and Development, 59, 6, 741-763 (2011)

6. Garris, R., Ahlers, R., & Driskell, J. E.: Games, Motivation, and Learning: A Research and Practice Model. Simulation and Gaming, 33(4), 441-467 (2002)

7. Ford, D.N. and Sobek, D.K.: Adapting Real Options to New Product Development by Modeling the Second Toyota Paradox. IEEE Transactions on Engineering Management, 52 (2), 175-185 (2005)

8. Kennedy, M. N.: Product Development for the Lean Enterprise: Why Toyota system is four times more productive and how you can implement it. The Lean Enterprise Institute, Cambridge, Massachusetts (2008)

9. Liker, J.K, Sobek DK, Ward AC, Cristiano JJ.: Involving Suppliers in Product Development in the United States and Japan: Evidence for Set-Based Concurrent Engineering. IEEE Transactions on Engineering Management. 43:165 (1996)

10. Bernstein, J.I.: Design Methods in the Aerospace Industry: Looking for Evidence of Set-Based Practices. Master Thesis, Engineering Aeronautics and Astronautics, Massachusetts Institute of Technology (1998)

11. Frye, M.C.: Applying Set Based Methodology in Submarine Design. Master Thesis, System Design and management, Massachusetts Institute of Technology (2010)