Dear Gemba Coach
How do I apply standardized work to product development?
This is an intriguing question and I don’t know if I can answer it directly. Standardized work is a very specific tool to address human motion and create production sequences with the least muda possible. I’m not sure the concept translates well in engineering. What is key to lean development processes is the notion of “standards.” Indeed every engineer I’ve come across who has worked with Toyota as a partner or a supplier has been surprised at how rigid Toyota engineers can be about their standards – refusing to even considering side-stepping a standard regardless of how good the argument. Equally surprising – and confusing – to observers is what constitutes an engineering standard and how it comes into being.
To return to your question, in assembly, the “standardized work” tool is derived from the Operation Standards Sheet, the basic job instruction tool about what specific standards must be met in order to achieve standardized work. In engineering work, I’d say that the equivalent of standardized work sheets would be checklists. As a tool, checklists are the concrete manifestation of two aspects of lean product development: hansei moments and development standards. Hansei occurs throughout of the development process as the time to take a deep breath, get together, and reflect deeply about what we’re doing, the mistakes we’ve made in the past, the mistakes we might make doing now, and where we’re going with the projects. In development, eliminating waste has a lot to do with avoiding bad mistakes that are wasteful later in the project, at the customer’s, in manufacturing or supply chain. One such mistake could be using in our development a rare material with a huge price volatility on the market, which would impose a profit variation according to market condition during the sales life of the product. Without a moment of pause and reflection such very costly mistakes are easy to make if one is exclusively focused on solving the immediate engineering problem.
Upside Down Perspsective
Engineering standards have many aspects, such as: shared components across products, standard product architecture, standardized manufacturing processes, standardized supply chains, test plans, design strategies and so on. In fact it often seems to outside observers that the entire development process within Toyota is steered by checklists and standards. To most engineers I know this sounds rather scary. Every company has its internal standards and engineers are supposed to follow them but they know that thankfully, they don’t. If they did, products would never get off the ground, and certainly never please the customer. Internal procedures are usually written by desk jockeys who know nothing about the real work of engineering and spend their time dreaming up impossible solutions to complete AMDEC analyses and so on. The key to good engineering is creativity, and it is a well-known fact that company standards are a huge barrier to innovation.
Here’s the conundrum: standards as we know them are a major impediment to clever engineering and yet they are the basis of lean product development. How shall we resolve this paradox?
As is often the case with lean, let’s turn our perspective upside down and look at standardization from the engineer’s perspective. Checklists are not all bad. In fact they’re often darned useful – not to tell us our work but to make us spot things we usually forget. Also, checklists can be a huge help to remember details in processes where we have a general idea, but can’t quite recall the exact phrasing. For instance, as a lean teacher, I have a book of standards. I carry around a banged up moleskin notebook where I’ve drawn and pasted in a variety of formats, explanations, definitions and so on. As a case in point, I have formats for the three basic documents of standardized work: the Standardized Production Capacity Sheet, the Standard Work Combination Table and the Standardized Work Chart. Now, with practice, I can probably redraw them from memory, but it’s still useful to check back when a specific question crops up.
Checklist Topics
So rather than a corporate handbook everyone is required to apply, laying down the law of thou shalt and thou shalt not, imagine that every engineer is offered that moleskin notebook on the first day at work and asked to behave as any inventor or artisan and fill it with their own sketches and ideas and, yes, standards. Any engineer worth his or her salt would be unlikely to write down the obvious (what is usually in the handbook). Instead, they’d start scribbling about quirky or interesting aspects of their job. Out of hand, one can think of:
- The various technologies to perform a given function and their description. For instance, my own notebook holds various ways of conducting introduction-level kaizen – they all do more or less the same thing, but in varied ways.
- The lead-time involved with each of these technologies. Some solutions are quick to implement, other take longer. Local sourcing might be more expensive than purchasing from the interior of China, but might also mean a shorter lead-time. Some solutions will be less capital intensive then others, and so on.
- Production costs after ramp up. Engineers tend to be familiar with prototyping costs that come out of their pocket, but not normal production costs on the line. None the less this is critical knowledge inasmuch as the two are not necessarily close.
- Schematics on the physical behavior of parts, as well as trade-off curves to express the scope of possible solutions (by example, maximum power (kw) vs; engine displacement (cc)).
- Competitor’s technical solutions to specific problems. When opening up a competitor’s machine a few weeks ago we noticed that all cables were the same length, some of them tightly folded and clipped when all the length was not needed; We wondered whether the standardization gain on one single cable balanced the added cost of using longer cables than necessary.
- Latest performance details of our technical solutions. Just a few days ago I was discussing with engineers designing automated test machines about the ratio of false positives tested by their machines (OK parts the machine considered defective – you run it again through the test machine and it turns out ok, sort of a blood test telling you you’re ill, but doing it again, you’re fine). They all agreed it was a serious issue but could not agree how much of an issue and had no data on hand.
- Main suppliers across the world – who makes what where?
- Key points to check on any drawing, consistency checks, known problems. For instance, during a design review session of a casted part, the manufacturing guy pointed out the designer had drawn different width of the casting. In the painting process, he explained, the part would go through an oven where areas of different width would heat differently, and create paint defects. Equal width across the part was essential to keeping the paint defect down.
And so on. Topics for checklists are endless. Essentially there are the checklists you draw to yourself to avoid making a mistake (check to turn off the headlights before turning your back on your car) or the checklists you keep about unfamiliar or interesting processes just to think about them and use them if they come up. In essence there are DO THEN CHECK checklists and READ THEN DO checklists. The point here is that the checklists in the engineer’s moleskin notebook will reflect his or her interests and quirks. How can that possibly become a “standard?”
Shut Up
From the engineer up, the main lean idea is yokoten (copy and improve) as opposed to apply best practice (execute and shut up). If maintaining the checklist notebook is the engineer’s individual responsibility, chances are that his book will look like mine: my own ideas are very few and far between. Most of what is in my book I have pilfered from more advanced person. Much like a student cutting up textbooks, in most situations one doesn’t know better than one’s betters – we’re all pigmies standing on the shoulders of giants.
And when we do know better, we’ve usually had to prove it. Standards are not cast iron rules – they are agreements that this is the best way to do this or that. Consequently, any one is free to challenge the standard at any time, but it means convincing others than your way is better; This does happen, but it usually requires quite a bit of work and being rather certain of one’s own facts. In actual practice the standards notebook will be filled with other people’s knowledge – precisely because the person feels it is his or her responsibility to guarantee it’s the best known knowledge. With the corporate handbook, on the contrary, everyone assumes that they know better in practice, and are wise to ignore it and follow their gut feeling.
This doesn’t sound like much of a way to enforce standardization, but in practice, it is. For instance, the engineering team leader’s folder of standards will have a great impact on how every junior member of that team learns their jobs and what technical decisions they make. The team leader will feel increased responsibility to have the best standards in his or her book inasmuch he or she now has to (1) pass on this knowledge to others and (2) work with other experts from other fields. This, in effect, is exactly how the scientific community proceeds.
Ultimately, knowledge is personal because no one can learn from you. Many knowledge management systems have echoed the corporate dream of taking the person out of the equation. Never works. Lean, on the other hand, is about achieving objectives THROUGH the development of people. Knowledge remains personal, but it is shared. Which makes for a good definition of what is a standard: shared knowledge.
The next step is moving from a personal standards folder to a product standards folder where all the checklists and knowledge pertaining to a specific product will be collate. On the gemba, the way I do this is simply ask development teams to start a new folder and throw in everything they know about the product – from PDCA experience: one sheet per knowledge item, which can be as simple as NEVER DO THIS written in large letters on a single sheet), until it progressively builds up into a checklists handbook.
Accelerating Product Development
The key here is to build up a representation of what we can change in the product design and what WE CAN’T – at least not without a major investigation project. The idea is that there is enough space around standards to find improvements that you don’t need to start by challenging what you actually know from experience (a bit silly, right?). The ultimate goal is that the product is so well constrained by checklists that a novice engineer should be able to design it fully without making obvious mistakes. These kinds of standards are essential to accelerating the product development process and to focusing on truly innovative areas, rather than fiddling with redesigning every door lock.
In practice, I don’t quite see how the specific tool of standardized work can apply to engineering. However, what we do know is that in order to learn any discipline, a person needs:
- A way to self-monitor his or her performance
- A way to self-monitor how they go about it
- Room to experiment
- Coaching by an expert.
Checklists provide self-monitoring about how we perform task. Checklists are about (1) knowing when to take a step back and, well, check and (2) making sure we’ve followed all the best known steps to succeed at a task. So if there is a tool that is close to Standardized Work in the product development field, I’ll argue it’s a humble checklist. The hard part is convincing your engineers that using and maintaining their own checklists will make them better engineers. Just like pilots take pride in their discipline in following checklists both for pre-flight routines and for emergency situations, we must somehow make engineers feel proud in demonstrating they’ve used the best knowledge available to solve the technical problems that confront them daily.
