Home > Gemba Coach> Engineering Checklists

Engineering Checklists

10/20/2011
Permalink   |   2 Comments   |   Post a Comment   |  
  |   RSS

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:

  1. A way to self-monitor his or her performance
  2. A way to self-monitor how they go about it
  3. Room to experiment
  4. 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.

2 Comments | Post a Comment
Peter Handlinger November 7, 2011

Michael is absolutely right about one thing in the product

> development process - creativity is a people driven exercise and can

> NEVER be automated via standardised work. The same principle applies

> to problem solving - elegant solutions to problems do not arise from a

> mindless adherence to process steps. Great artists don't paint by

> numbers ... but they do have a deep insight into their chosen topic

> through studied observation. And this is where some form of

> standardisation may well be appropriate ... to guide the process of

> making those breakthrough 'non obvious' connections that lead to really great solutions.

>

> But how to create such an environment, or space if you prefer, that

> will 'grow' those non-obvious connections? Unfortunately a bit of

> discipline is required here, and this is where some form of standardisation is necessary.

> A continuous recording of personal experiences in a journal is

> extremely useful as Michael suggests. This can then be translated via

> collective discussions into an engineering "way to do" manual.

> Sometimes these manuals are referred to as SE Manuals (simultaneous

> engineering) in Toyota. Michael has given good examples of the type of

> things that could go into this type of manual. Please note the use of

> the word 'manual' as opposed to 'procedure' ...

>

> Although the Hansei concept is mentioned I believe that this is not

> emphasised enough. On the completion of each project / initiative it

> is imperative that some form of reflection takes place. No one likes

> doing this. After all, the product is in production and we all sweated

> bullets getting it there so what's the point of digging up all the old arguments?

> Besides we can't really remember all the details anyway. Reality check

> here!! The DNA of an engineering development process is established

> via this 'post mortem'. If this reflection is not fed through back

> into "how we do things" then it will remain at a personal level and

> the organisation will continue to make the same mistakes over, and

> over ... If anything, this is one of the 'standardised work' tools that must be done.

>

> Another area that is close to standardised work is that of project

> status reporting. Consider it a 'short interval control' mechanism in

> the project world. Regular reviews (with a reflection element) must

> take place. The simple point of this is that any abnormality is

> spotted early on and appropriate countermeasures can be taken. This is

> unglamorous work to do - but so valuable to keeping a project on track

> (Much more awe inspiring to be the hero of your own disasters!). In

> this context I would like to add the seemingly obvious exhortation to

> VISUALISE everything - your plans (and the progress), the problems,

> the solutions ....  this builds the shared knowledge practice mentioned in the article.
Durward Sobek December 16, 2011
Great post on checklists for engineering knowledge!  I think other standardized work can also be applied elsewhere to improve product development effectiveness.

As Michael said, standardized work is simply the best known way to get the work done (and everyone who does the job using the best known way).  As such, there are numerous routine tasks that can and should be standardized.  Why waste creative energy in getting a purchase order through the system and approved, for example?  Streamline and standardize the routine stuff so that you can focus creative energy on things that add value to the customer.

Also, experienced product developers evolve highly effective ways of doing knowledge creating tasks, whether it be how to conduct an effective focus group, setting up and running a product simulation, or developing specifications for new manufacturing equipment.  Concepts of standardized work can be employed to deploy that experience more broadly to create increasingly more effective and productive ways to get the work done.  In essence, the "folders" Michael describes for technical knowledge can also include ways of working.
Other Michael Ballé Related Content

Gold Mine Master Class

Books

Articles

Webinars