Dear Gemba Coach,
What steps do you start with to introduce visual management into a product development facility?
(During The Way to Lean, a free webinar on the “lean trilogy” approach to deeply understanding and applying kaizen daily, we received the above question plus dozens more that we didn’t answer when time ran out. Presenter Michael Balle will answer them in the Gemba Coach columns he writes for LEI. -Ed.)
The first step is to discuss with the product development department how visual management is going to radically change his or her own management practice and what it does. This means agreeing on the fact that:
- Engineers need space to think to understand what a good design is – which means creating a visual space to see the various debates and not remain a slave to the workflow. Engineering management needs to agree that engineers should realize that solving their little part of a development problem without regard for the product as a whole is counterproductive. Many engineering managers assume that if the project plan is kept, and if the gate reviews are maintained, the product will come out alright, which is plain nonsense. A successful product is one that customers like and want, and the result of clever, mindful design by talented engineers, not of a bureaucratic process.
- Teamwork is essential to good product design – teamwork in the sense of solving problems across functional barriers. Not only do engineers need space to think, they also need a place to come together and share ideas with other stakeholders such as marketing, sales, service, supply chain, and production. Visual management is a way to visualize problems so that all can share each other’s constraints and spur creativity.
Consequently, each engineering department will develop its own visual management specifics according to the path of learning and which issues it chooses to face or to postpone to a later date: visual management as a whole is path dependent.
- The first step to introducing visual management in a product development facility is therefore to clarify the expected outcome of such an approach: what gains do we hope for? Which performance metrics do we want to improve?
- The second step is to explore, with the engineering manager, the various modes of visual management in the lean field, so that he or she can pick the one to experiment with first.
- The third step is to keep growing the visual management system as one would a tree, or rather, a garden and keep challenging it in terms of how well it achieves its purpose, so that the visual management system itself remains alive and growing and continues to support engineers in better thinking, to make better products.
To help you get started, here are some visual tools to use.
The Wall
The first aspect of visual management I’ll try to set up in product development is therefore a wall dedicated to customers and products showing various specific customer usages and various aspects of the products, radar charts of performance, and usually a “measles” chart to highlight all the places on the product where customers complain about quality issues.
When things go well, this customer wall leads to a fundamental discussion on the product “concept”, and more specifically:
- What are the standards of the product we will carry-over from the next generation.
- Which features we need to change to fix a quality concern, improve basic performance, and reinforce what customers can’t get elsewhere.
Faking Kanban
The second big lean topic in engineering is “just-in-time (JIT).” Engineering, just as production, tends to be run by workflows where, when they visualize it, managers put their process schedules on the wall. This doesn’t help much other than stress the people who appear as “bottlenecks” (they’re usually not the slowest engineers, but those who have the toughest problems). Beware of fake kaban coming from IT agile practice which is nothing more than a process flow with post-its (tickets, jobs) accumulating at different sections of the visual board. This is NOT just-in-time, this is ERP thinking on a wall.
In practical terms, to try and visualize JIT in engineering we will start with:
- A delivery board that shows the expected hand-over to production of each project (circle is planned, triangle is late, X is abandoned) and ask engineers to review this board once a week to make sure their anticipation of when a project reaches the factory remains on track. The difficulty here is that projects that hit trouble tend to slip back and projects that do well stay at the same date, so now all projects land in the plant at the same time. A plant can do many things, but not handle several starts of production at once, so you’d better keep tracking that.
- A personal kanban board to make sure engineers are not overwhelmed with tasks and keep priority scheduling out of engineers’ desks. Engineers must be free to focus on their work and not move from one open file to the next. By setting up a simple kanban, we can visualize what engineers are working on at any one time and keep the queue at a manageable level rather than overburden each person.
Stop at Defect
Jidoka, or “stop at defect” is somewhat trickier to implement, but here again visual management does help, although not perfectly. The main issue I’ve come across with “stop at defect” is not so much that engineers won’t call when they have a problem, but rather they don’t see problems until too late. To compensate for this, we work on posting clear product architecture and have regular discussion sessions about the interactions between the different functions. Communication happens mostly through A3 type explanations of typical problems. The aim is to say to engineers, “When you come across this configuration (as in: this alignment of planets) please stop and let your manager know, because ignoring it is going to cause some grief later on.”
So far, I’ve not found software that automatically highlights these kinds of problems and I don’t know whether Toyota has developed some clever solutions to make engineers’ work easier, so we do it the old fashioned way of presenting problems or potential problems as they arise and making sure everyone is aware of interconnections within the product design and manufacturing issues that needs to be taken into account very early on.
Production Standards
The fourth topic that is core to lean engineering success is standards. If we take the high view, Toyota’s competitive edge is largely built on a strategy of expanding its product range (products, not options) on the same production facilities. In other words, it can introduce a new, risky product for a very small market without carrying all the financial risk of new facilities by assembling it on existing production lines. This, as you can guess, requires quite a lot of engineering savvy.
A fourth area for visual management therefore is dedicated to the production line intended for the product and the standards that need to be respected (such as sequence of assembly, parts, etc.) to make this work. This is very hard for most engineering groups who tend to think in terms of product engineering then manufacturing engineering, then production, then supply chain, but creating a concurrent space for discussions to happen upfront throughout the project delivers huge benefits for the company as a whole. These standards will then echo the standards engineers keep as a personal knowledge base in notebooks or checklist folders.
