Be among the first to get the latest insights from LEI’s Lean Product and Process Development (LPPD) thought leaders and practitioners. This article was delivered to subscribers of The Design Brief, LEI’s newsletter devoted to improving organizations’ innovation capability.
Like complex system designs, most development programs struggle at the interfaces. That is, managing dependencies between various required disciplines like design, software, engineering, manufacturing, and others is the greatest challenge in development. This is especially true when companies attempt to work concurrently without understanding these dependencies. In my experience, this may be the single greatest source of rework, churn, delays, cost overruns, and quality spills. Which often leads to a divisive, combative, and frustrating working environment for everyone involved.
Lean Product and Process Development (LPPD) is a set of principles, practices, and tools designed to enable people from diverse disciplines to work together to create successful new value streams. One of those tools is the obeya management system. Obeya, as pretty much everyone knows, is a Japanese word for “big room.” But as my friend Andy Houk, vice president and general manager at Schilling Robotics, says, it’s so much more. It is where the program comes together on cadence to improve collaboration, communication, and coordination through the transparent, proactive management of those interfaces. When done correctly, it is a powerful management system that helps people work together more effectively, not just a place to hang stuff on the walls.
There is currently some (unimportant) debate about the genesis of obeya, but my first experience of it as a management system was in 2003 when my coauthor Jeff Liker and I had several meetings with Takeshi Uchiyamada, the chief engineer who led the development of the original Toyota Prius. This breakthrough product demanded rigorous and effective management of the many interdependencies across the multiple disciplines required to integrate the technologies required to create this industry-disrupting product. Obeya provided exactly what the Prius team needed to enable their success.
10 practical lessons from experience
Since then, I have participated in, helped create, or observed hundreds of obeyas in automotive, aerospace, health care, electronics, energy technology, appliances, and many more industries. I would like to share a few thoughts on what I have learned about successful obeyas.
1. Obeya is not senior management entertainment. It is a tool for the development team to manage their project and should be designed accordingly. A fixed and flexible approach to obeya design is usually best. Provide guidelines and best practices to teams, perhaps even some minimum requirements, but leave the team plenty of room to customize the space to meet their specific needs.
2. It’s okay to be “red”. It’s not okay to stay red. Things go wrong in development — lots of things. Obeya requires transparency. People will not be forthcoming if they get wire-brushed whenever they bring up an issue. Consequently, it must be safe (normal) to bring up a problem. However, it can’t end there. Obeya is not a place to just dump your problems. If you are reporting a red project status, you should also be able to answer the following: What is your plan to get to green? What is the date to green? What help is required? What are the implications for the rest of the program?
3. Make the plan and the objective obvious — including all critical glide paths. Who is the customer? What are we trying to do? How do we propose to do that? What are the critical attributes of this product or service? What’s our plan to deliver? Who owns what part of the plan? Remember, obeya is more than a schedule.
4. Focus on leading, not lagging indicators. Allow the team time to react and fix issues. It doesn’t help to know something will be five weeks late, the day it is due. Not much you can do then. Work back from the critical event –- what step is most likely to determine the outcome of that deliverable?
5. Use effective integration points defined by the quality of event criteria, not just activity. Too many programs define integration points or milestones solely by an activity. For example, take the first virtual build. In that system, you accomplish the activity — so milestone met. That can be incredibly misleading. How many designs were at the appropriate level of maturity? How many open issues did you have? What was the level of supplier or manufacturing readiness? (i.e., can we even deliver those designs?). Set minimum quality thresholds.
6. Transparency + Cadence = Accountability – Drama. In my early days, I was in more than my share of table-pounding, threatening, and even chair-throwing program meetings. It was drama that said much more about the leader than it did the program team. And it created an environment where your goal in reporting status was to get off stage and not be the slowest gazelle.
Compare that to Alan Mulally’s “That’s okay, we’ll be back next week, and I know you will have a better plan” in his famous Business Plan Reviews. That is the power of transparency and cadence. No yelling, no threats, but also no place to hide because we will keep coming together.
Just a quick note about obeya cadence and location. Both can vary depending on the needs of the project/program. Early in the program, the team may only need to come together every two weeks. But during times of intense testing, build, or launch, the team may need to meet every day. Similarly, the obeya may be located in design at the beginning of the program, the prototype shop in the middle, and the manufacturing plant during launch.
7. Participation is not optional. Everyone is included. Everyone understands the plan and their responsibilities. Everyone participates. This includes key suppliers or supply chain leaders as required.
8. Individual workstream leaders talk to their workstream members. They know best and are the people responsible.
9. Establish/utilize an effective help chain. Occasionally, problems will require help beyond the capability of an individual team. There must be a predefined, effective method for raising issues and helping the team in a timely manner. Hint: It’s not adding more senior management report-outs.
10. Review the program at the right level. Don’t waste everyone’s time down in the weeds solving an individual problem. Do that afterward. Your focus should be on managing the interfaces. But at the same time, you want to resist “traveling hopefully” with large undefined blocks of time. Like many things, it’s a balance that must be maintained by skilled leadership.
Leveraging speed and precision
Multiple disciplines working together concurrently is the key to increasing your speed to market. It does not have to lead to enormous amounts of rework and waste. The key to success is understanding the actual work to be done and the cross-workstream dependencies. Designing your development process to leverage these dependencies is the first step to doing this well.
But your development process can’t possibly anticipate every potential failure mode and design in countermeasures. Nor should it. This would create a bureaucratic process that would, at best, take even longer than a serial process and, at worst, be completely impossible to execute. Obeya enables you to manage your dependencies in real-time. You’ll see a potential conflict on the horizon and have a ready-made forum to react, course correct, and keep everyone on the same page.
When taken together, effective development process design and the obeya management system will help your development teams execute with a level of speed and precision that will serve as a competitive advantage.
Your challenge this month is straight forward. Utilize the experiences shared by John Drogosz, Steve Shoemaker, and the team at TechnipFMC to improve the way your development teams communicate, collaborate, and coordinate.
Good luck.
Download the latest issue of The Design Brief.
Designing the Future
An Introduction to Lean Product and Process Development.
