FEATURE – In a world of disruptive innovation, being faster and smarter at developing new products has become critical. The authors explain why set-based concurrent engineering is the answer, and why a game is the best way to learn it.

Words: Monica Rossi, Assistant Professor, Industrial Engineering Department, Politecnico di Milano; and Roberto Priolo, Managing Editor, Planet Lean

Between the 19th and the 20th century, an exhilarating competition to conquer the skies was taking place, as scientists, inventors and aviation enthusiasts from around the world attempted to build a heavier-than-air machine that was able to fly. The Wright brothers famously succeeded in this extraordinary endeavor, just south of Kitty Hawk, North Carolina in December 1903.

Orville and Wilbur's story is well known around the world, but what most people are not aware of is the method that the two American brothers used to develop their flying machine. Questioning the prevalent approach to design, they started to look for alternative ways to reach their objective and decided that the first thing they'd need to do was address their knowledge gap (they were not experts in aeronautics). So they set out to conduct in-depth observation and repeated testing of prototypes of sub-systems, which allowed them to discover the trade-offs curves that existed between all the variables they were working with. The design of the machine only came afterwards, and it's important to note that their first attempt was successful: it took them less than two years over a four-year period (and quite a small investment) to fly their piloted machine.

To clarify why the Wright brothers' approach succeeded where everybody else failed, let's look at Samuel P. Langley – another pioneer of aviation – who spent more than 15 years (and 70 times the amount of money spent by Orville and Wilbur) to build his "airplane." It flew, but he never managed to successfully pilot it. His method was a traditional form of point-based engineering that had him evaluate one option at a time. This method tends to generate massive delays and rework if any problems with the design are discovered at any point in the process (in fact, the closer you get to the production phase, the more expensive the changes will be).

Conversely, the pioneering approach to product development and innovation used by Wright brothers was built on ideas that are remarkably similar to what Durward Sobek and Allen Ward defined as "set-based concurrent engineering" (SBCE) in the mid-1990s – a staple of lean product and process development today.

As one of us (Monica) wrote with Jim Morgan and John Shook in the Lean Product and Process Development chapter of The Routledge Companion to Lean Management (2017), relying on learning and creating reusable knowledge makes the lean product development process both effective and efficient in avoiding mistakes in the late phases of design and therefore in delivering customer value in the smoothest way possible.

In SBCE we don't make any decisions until the necessary knowledge has become available to us (just like Orville and Wilbur filled their knowledge gap before jumping into devising a solution), and engineers test several design alternatives in parallel, progressively eliminating options as they obtain enough knowledge about the performance of the sets, until only one solution remains.

This appears counterintuitive to many people at first. In fact, Ward, Liker, Cristiano and Sobek (1995) went as far as saying that this might just be the biggest paradox that we can find in Toyota's business system. At the beginning, it might be hard to understand why SBCE is effectively forcing us to delay decisions, to communicate "ambiguously," and to explore a seemingly excessive number of product alternatives or prototypes. Yet, this approach to developing new products makes perfect sense: delaying decisions until we know everything we need to know means being sure we are making the right decisions; what may appear as ambiguous communication is actually a cautious way of sharing the information that is currently available; finally, working on a set of prototypes at once (which modern technology allows us to do virtually in a very cheap and easy way) means evaluating several potentially successful options, thus speeding up our innovative process.

Because of this paradox, even organizations that are deeply involved in lean product and process development often find it difficult to grasp the thinking behind SBCE. The impression this powerful methodology gives us at first is that we are wasting time and overcomplicating the process, and getting past this first assessment can take a while. That's why one of us (Monica) and her colleagues at Politecnico di Milano have developed a serious game that, we think, greatly helps practitioners understand what SBCE is all about by showing them why until now they have done product development the wrong way.

UNDERSTANDING SBCE, ONE BRICK AT A TIME

A serious game presents a complex reality or problem in a simplified way, which becomes truly invaluable when we are dealing with elusive concepts and hard-to-grasp methodologies like SBCE. What also makes them particularly effective is that players feel comfortable taking risks and experimenting, because no real money is at stake, and have a lot of fun while learning. Learning while having fun in a safe environment where we can make mistakes helps us to understand and remember!

So how does the SBCE serious game work?

We ask participants to use LEGO bricks (pieces come from a pre-defined catalogue – for example, we have x number of blocks that one-stud-wide and ten-stud-long) to build an airplane that can both fly and comply with customer requirements. The airplane has four sections – body, wings, tail and cockpit – that participants can assemble in any way they can using components (the LEGO bricks) until they get to what they think is the best combination and solution to the customer's problems.

Invariably, people get it wrong all the time! They think their plane can fly, but it can't, or that the customers will be happy with the result, but it often isn't the case. The problem they face is that there are so many requirements and technical constraints to take into account that they either forget some of them or simply can't find a way to satisfy them. And so they keep iterating, through trial and error, but very rarely do they get to the right combination of components. Don't forget this is just a game with airplane made of four sections – imagine the complexity that companies Boeing or Airbus have to sort through as they design their aircraft (which have millions of components).

During the first phase of the game, we ask participants questions like "Is this the only option you can provide me?" or "Are there other options? If so, how many?" No one can answer these questions, and the truth is that no engineer can answer them unless they base their product development activities on the formalized knowledge that set-based concurrent engineering generates. Effectively, what we teach with the serious game in a shift in mindset.

Once the shortcomings of point-based trial-and-error have become clear to participants, phase 2 of the game begins: we provide them with a piece of paper with trade-off curves, which provide the relationship between variables (for example, the number of passengers with the width and length of the body of the airplane). This information defines the design space in which you need to move, by giving you the combinations of variables that comply with customer requirements and those that don't: for instance, if you have to need to fit between 50 and 100 passengers in your LEGO airplane, your body cannot be narrower than 2 studs and longer than 12 (with all the combinations of pieces in between). Critically, this means that all the combinations on the trade-off curve sheet that display a width smaller than that 2 can be ruled out immediately, because they will never lead to a working prototype. The same goes for any combination with a body length higher than 12.

Narrowing down the number of possible options makes it exponentially easier for us to identify a combination that will give us a working prototype. More importantly, it allows us to get closer to our solution without spending resources (be it time or money) on unviable projects, and without having to carry out expensive rework. This means that we will be able to develop more products more quickly and more cheaply – in other words, SBCE boosts our ability to be innovative, much like the Wright brothers did. And isn't this something every organization should be paying attention to?

Monica has now played the SBCE serious game with over a 1,000 people (including students and practitioners – even working in firms advanced in their lean product development efforts) and they all struggle with same problems. They have a hard time understanding how formalized knowledge is created, how to find out what they need to know, how they can respond to very specific customer requirements, how they can avoid rework, how they can unleash the creativity of their people, and so on. If you are asking yourself these or similar questions, this game is definitely for you.

_{THE AUTHORS}