Takeshi Uchiyamada had a problem. He had just been named Chief Engineer for arguably the most revolutionary product in Toyota’s history. The goal for this program, initially identified as G21, was to achieve nothing less than 1.5 times the fuel economy of Toyota’s best small cars and develop it on an extremely compressed timeline. To make matters worse, Mr. Uchiyamada lacked the technical depth required to develop and commercialize the advanced hybrid technology that would be required. In fact, no single person at Toyota did. He quickly realized that he would need an unprecedented level of collaboration, transparency and speed of decision making to make this program a success.
Consequently his first pathbreaking innovation had nothing to do with engine technology. Recognizing that his job would be to effectively integrate the efforts of diverse experts and keep the project on track to achieve no compromise targets for performance cost and schedule, he created the “obeya management system.” In this system he met every two to three days with all required technical experts in a room in which all pertinent information was posted on the walls. This information was available to everyone on the team at any time. The G21, which the world has come to know as the Prius, went on to revolutionize the auto industry, dramatically raising the bar for fuel economy and leaving competitors years behind. And the obeya system, credited with making a major contribution to the Prius success, became a development staple at Toyota.
I first heard this story nearly 18 years ago while meeting with Mr. Uchiyamada during my research at the University of Michigan. At the time he was working with a team of Toyota engineers who were tasked with standardizing and teaching obeya throughout the Toyota development community. Obeya, of course, is a Japanese word for big room referring to the large open room required to house the functional technical experts required on the Prius program. Obeya, of course, is a Japanese word for big room referring to the large open room required to house the functional technical experts required on the Prius program.
The challenge to the Toyota team was to capture this powerful system for collaboration and transparency without the ability to co-locate all program teams. They described the system basics as:
- Engineers are not co-located. The Functional Engineering Staff Leaders meet with the CE on a varying cadence.
- Paper-based visual management is the key to effective communication. The walls are plastered with important program information including information on design alternatives, test results, status to attribute performance targets, cost status, status to schedule, and supplier readiness levels. The team walks the walls at regular meetings and sub-teams meet there often between meetings.
- The obeya location moves with the program. Starting in Engineering, moving to prototype and finally to the plant for launch, the cadence of meetings also change as the program progresses. Typically increasing in frequency to daily meetings as the program moves to launch. For a fuller treatment of both the Prius program and obeya history you can reference the Toyota Product Development System.
During my visits to Toyota City earlier this year I saw that obeya at Toyota has continued to evolve through careful PDCA. There were innovations such as adding CAD and simulation capability in order to facilitate real-time design discussions. But the heart of the system remains visual management and the intent to improve communication, transparency and cross-functional integration in order to quickly identify and solve problems.
Transparency and collaboration were also the essence of Alan Mulally’s message at Ford when he said, “You can’t manage a secret” (and I would add, “…and you can’t solve a problem you’re not aware of.”) He challenged us to increase honest, fact-based communication and improve cross-functional collaboration across the enterprise. One of the ways our team responded was with an “obeya system.” Obeya was not only used to manage program performance, but also to integrate cross-functional teams, as well as to help manage the global functional engineering business, in the creation of the global product development system (GPDS).
I was reminded of these experiences when our LPPD Learning Partner companies came together to learn and share their outstanding work in Davis, California last month. While experience levels and specific practices varied across companies, each company was experimenting with obeya and all reported performance improvement. Several teams reported “best-ever” results. In our subsequent discussions we learned many nuances of how they were each leveraging the power of obeya. However, all of them found that the real benefits of obeya were in transparency, speed of problem resolution and team engagement.
So the next time you are tempted to get drawn into circular arguments about what metrics or graphs to share, where they should be placed in the room, or even if obeya should be spelled with one O or two (yes, I have actually heard that), think about Takeshi Uchiyamada, Alan Mulally, our learning partner companies and the real purpose and power of obeya. Consider: how can you best leverage obeya to better engage your entire team and dramatically improve your performance?
PS:
We had a fabulous day at the University of Michigan Hospitals last week. Together we identified many opportunities to apply LPPD to improve patient-centered care and deliver ever-better value. This promises to be an exciting frontier for LPPD.
It was great to see the teamwork developing across our partner companies at our most recent learning event. Each company was sharing openly and supporting the progress of the others. Topics included our Chief Engineer concept paper, enterprise transformation, obeya and A3 for developing people. Our LPPD learning partner model continues to evolve and become more powerful. LPPD senior coach Matt Zayko will be writing up and sharing the event more fully on our site leanpd.org.
Designing the Future
An Introduction to Lean Product and Process Development.