Earlier this month, we had the pleasure of participating in a lean product and technology development workshop through Israel Lean Institute (ILE) in Zikheron Ya’akov.
The workshop – designed and led by Dr. Monica Rossy from the Department of Management, Economics, and Industrial Engineering at the Politecnio di Milano – integrated “serious games” into the program. After learning the context and basic principles of Lean, Rossy led us through an exercise to estimate and measure the levels of waste in our organizations, and in particular, our new product development systems.
To do this we were given an assignment to build a model plane out of legos, made up of four pieces: body, cockpit, tail, and wings. We received clear instructions, drawing plans, and specific demands from the customer. Then off we went (but not of course before we chose a name for our development unit)!
Our first real problem to solve was our management system, including organizational structure. Would we divide up into separate departments? work together? We decided to work in parallel – with all team members being responsible for a sub-system within the entire system (the plane).
By the first planning session, we understood that there were a few possible designs for each subsystem of the plan, so we decided that each of us would plan his/her own part and come back with the data on the possibilities available to us. After each team finished defining delineating its planning space, we discussed team integration. The body of the plan was the center of the structure, so the team planning the body began to draw the space of relevant information and possibilities (according to our knowledge of what constituted value for the customer as well as what we knew about our technical limitations). Then we wrote up all of the possibilities together.
Next, we returned to the demands of the customer and began to rule out the alternatives that did not meet their specific requirements (SPEC) or our technical limitations. Initially, we ruled out all of the models that exceeded weight requirements. Afterwards we ruled them out according to the number of passengers. And lastly, according to the length of the wingspan. We were left with two options to meet customer requirements, and we raised the idea of building two models. In the end, we decided to produce only one.
After construction, we moved on to testing and ran calculations according to our parameters. For quality control purposes, each team did calculations separately. We found faults in the suitability to the technical requirements, and the system went through another round of adaptation to the demands and technical frameworks. We corrected our mistakes and decided to “send” the prototype out to the customer. Just before doing this, teams documented the parameters of the product in preparation for presenting the model to the customer.
And here came the surprise… Our customer looked at the physical model and came up with new demands! What could we do? We went back to the drawing board!
It became apparent that our investment in an in-depth study at the beginning of the process – we had front-loaded development – had been worthwhile. The changes mandated by the customer’s new demands could be made quickly and effectively. Prior examination of the technological restrictions and scope of unfamiliarity gave us an idea of our risks as well as where we had knowledge gaps. Exploring our options and technical limitations early on helped us save on resources and respond quickly as we moved down the value-stream. The team learned that there was no need for more than a single integration meeting in order to make corrections and go back to the customer with an updated product.
So, what happened here? We had fun learning about a complex technical engineering system while learning how to begin to thinking about lean product and process development. We came to understand the basic lean view of development: the purpose of the entire technical development process can be found in the in-depth understanding of the customer’s needs; without understanding how a new product or technology creates (subjective) value for the customer, we cannot focus the energy, innovativeness, and creativity of our people. Through simulation, it’s possible to understand how critical it is to understand the demands of the customer, to validate them from the beginning, and to work with the customer throughout the entire process in a transparent and cooperative manner. Just this prevents a tremendous waste of resources (knowledge, time, and capital).
We must also remember that customer does not always know all of his/her demands, nor is he/she aware of product limitations, and thus it is important to prepare a concept or prototype that makes these clearer to the customer and the development team. It becomes necessary to define precisely how the customer understands the value of the product and what its goals are. The planning – not just the product! – must meet the demands of the customer.
Two other teams worked in parallel to ours, and it was interesting to see that each of the groups approached the problem differently. In planning a new product, it is important to give each group the design space it needs. Based on our early learning and knowledge scoping, we were able to determine the greatest number of alternatives to meet customer demands and examine them according the additional parameters of cost and benefits.
What’s the use of games? The serious game that Wilbur and Orville Wright played not only resulted in the first aircraft, but also the most effective way to develop and introduce new products and technology. The Wright brothers’ adventure was followed up by innovation in product development at Toyota. and later the product development method Allen Ward pioneered – Set Base Concurrent Engineering.
Why not try a serious game as you work to make new product and process discoveries?
