Comments on: Test for Actual Use, not Intended Use

By: Jamie Flinchbaugh

Jamie Flinchbaugh — Sun, 03 Jan 2010 00:05:33 +0000

Great story with a great moral Scott. Thanks for sharing.

By: Scott McDuffee

Scott McDuffee — Sat, 02 Jan 2010 21:45:51 +0000

Not an apples-to-apples comparison but your story reminded me of one a previous Ops VP mentor shared with me to inform a challenge I was facing at the time.
“A prominent brand of washers and dryers was having costly difficulty with returned damage product. With a little scrutiny, it was determined to be coming almost totally from one location of a big box home improvement store.
Memos and admonishments began. The problem was not corrected. The feedback was escalated. Bigger and bigger players were involved. Edicts were issued; the threat of stopping business with this location was imminent.
Then, someone from the brand said – let’s go see {What seems automatic for some, comes harder to many. We would say they went to gemba}. Waiting and watching at the delivery docks when the washers and dryers arrived, the simple discovery was that the washers and dryers were unloaded by the same practices and same tools as many other products.
In fact, the use of a dolly designed for lifting cylinders (water heaters) was causing immediate damage to almost every cubical (washers and dryers) product. No one previously had bothered to observe.
The washer and dryer company purchased the correct dolly, made them available {we assume with visual controls and standardized work to sustain}, and for minimum investment avoided a catastrophic situation.”
The moral of the story –
Go to the process; talk to the people; embrace problems.

By: Jamie Flinchbaugh

Jamie Flinchbaugh — Tue, 29 Dec 2009 13:42:25 +0000

Great stories Karen. Good reminders that this is a mindset or behavior problem, not a process problem. If we don’t welcome insight into how things might fail when used, no tool or process will help you.

By: Karen Wilhelm

Karen Wilhelm — Tue, 29 Dec 2009 13:30:37 +0000

Two stories:

When Alan Mulally first came to Ford, he arranged to meet a panel of testers at the Consumer Reports facility and took along a group of engineers. A woman had been testing the new Ford Edge and said that she had been grocery shopping on a rainy day. When she got to the vehicle with her bags, she found it difficult to operate the cargo door and juggle her groceries. We’ve all been there. The engineers proceeded to tell her why the vehicle was the way it was, actually beginning to argue with her, and Mullally basically told them to shut up and listen.

The other is about Mike’s first IT supervisor at Ford in the mid-80s when they were writing a new version of their material supply system for the assembly plants. Remember that if there’s a problem with this system, the plant goes down and all hell breaks loose at the data center. Jim sat up nights trying to come up with ways to break the system, and the programmers would come in the next day and have to find a way to prevent that failure. A team-based FMEA would probably have been better than relying on one obsessive person, but he taught Mike to have a passion for anticipating problems and respect for the user who might come up with a condition that never occurred to the programmers in their Dearborn offices.

Of course, in those days, each programmer took a turn on the night-call list. No remote access–if a call came at 2 a.m., he or she had to get out of bed and drive to the office and sit there alone trying to fix the problem while the plant guys kept reminding him how many millions it was costing. That’ll make you build in reliability!

By: Jamie Flinchbaugh

Jamie Flinchbaugh — Tue, 29 Dec 2009 12:48:39 +0000

Rob, it is, but that’s doesn’t solve the problem. If you do a focus group, and ask them about features or use, they will often tell you about how they plan to use it. That doesn’t necessarily match how they ACTUALLY use it. And D and P FMEAs only work if you KNOW what the failure modes are and ask the right questions. FMEA doesn’t solve that problem for you, it only gives you the template on which to capture it.

By: Rob

Rob — Sat, 26 Dec 2009 12:23:30 +0000

Is this not why you should routinely conduct D and P FMEAs? And also conduct formal VOC events; whether or not it’s QFD, focus groups, individual interviews, contextual inquiry, ethnographic techniques, etc

By: Mark Graban

Mark Graban — Thu, 24 Dec 2009 17:18:03 +0000

It’s good that you emphasize “going to the gemba” as we’d say in the lean world. That doesn’t apply just to going to the shopfloor (or the nursing unit) but also applies to going to see your real customers using the product in every day life.

By: Jamie Flinchbaugh

Jamie Flinchbaugh — Thu, 24 Dec 2009 10:12:37 +0000

Jon, that’s a very interesting concept. It is rare that I get to meet a true anthropologist that is studying business, but every time I do I am impressed both by their observations and also their process. I think large organizations that can afford it would be wise to put someone from this background on their organizational development staffs. And perhaps we should train OD professionals in the methods of anthropology as well.

By: Jon Miller

Jon Miller — Thu, 24 Dec 2009 08:37:23 +0000

Mmm. This is a great post. If only we could bring more cultural anthropologists into the modern corporation.

By: Jamie Flinchbaugh

Jamie Flinchbaugh — Thu, 24 Dec 2009 01:50:40 +0000

Tim, DFMEA is a tool, not a process. It only helps you capture and plan around known failures. If you are evaluating a product from how it would actually be used, those failures wouldn’t show up on your DFMEA.

I have forgotten about the VW story Jim, that’s a good example. And thanks for sharing your example Ankit.