Industry news has been hinting that Silicon Valley and Detroit are engaged in a fake war over high tech cars, each taking over the lead in the tech race any given month. Both are vying to develop faster and leaner by efficiently focusing on only the crucial work with entrepreneurial passion. Functional safety certainly bridges both worlds.
But don’t automotive industry standards like ISO 26262 get in the way of lean processes?
Take, for instance, the FMEA. It is probably a fair statement to say the typical automotive engineer would not associate words like “crucial,” “efficient,” and “passionate” with the FMEA work product. Although, one should first review the Safety FMEA as discussed in Jody Nelson’s blog The Safety FMEA.
Admittedly, the FMEA can be tedious, uneventful, and uncomfortable when it comes to systematically poking holes in the product an engineer is proud of. But what can be done about the hang-ups surrounding the FMEA? And what does the FMEA have to do with the lean, entrepreneurial philosophy called “fail fast?” Let’s try to answer both together.
To begin, let us review what fail fast is, according to Margaret Rouse at TechTarget.com:
- “Fail fast is a philosophy that values extensive testing and incremental development to determine whether an idea has value… [and] is often associated with the lean startup methodology.”
- “Failing fast seeks to take the stigma out of the word ‘failure’ by emphasizing that the knowledge gained from a failed attempt actually increases the probability of an eventual success.”
Rouse also acknowledges Eric Ries, the fail fast champion inspired by Japanese lean production methods, who talks about the concept of validated learning.
Those familiar with functional safety will immediately see the parallels to fail fast and validated learning. For example, in the early concept phases, safe product development requires testing of preliminary assumptions in order to document how they fail. That is to say, in the effort to succeed quickly, functional safety fails fast and generates validated learning.
Good safe product development is good lean product development.
Safe product development did not begin with ISO 26262. The FMEA has been an automotive industry standard document of validated learning since 1994. So, if this crucial piece of lean entrepreneurship has been around so long in automotive design, how has it fallen to one of the least desired engineering activities, and sometimes viewed as the least helpful to the product engineer?
If there is a lack of passion when it comes to completing an FMEA, it may be because management is just asking the engineer to go through the motions. At the 2009 IndustryWeek Best Plants conference, keynote speaker John Shook, a well-known lean production guru, said, “You never want to waste any employee’s time or effort. That’s the most disrespectful thing you can do” [1].
- Does management ask the engineer for direction from the FMEA’s low RPN results?
- Does the FMEA really give the engineer authority to require additional work that may not even be in their department, which they cited to justify a low RPN?
- Does the FMEA really give the engineer authority to approve of their customer’s test results during validation stages, which they cited to justify a low RPN?
If any answer to the above questions are no, then the ideas the engineer generated during the FMEA are ahead of their time. Like accumulated inventory that never goes anywhere, the engineer has wasted work. This eventually becomes a burden in their workflow.
This is a familiar story in functional safety. We point out a safety related failure in an FMEA and the engineer says, “No, that is not safety related because another team’s system can switch to a fail-safe mode and no one would get hurt.” The engineer’s hesitancy to acknowledge the safety risk in her FMEA shows she does not feel empowered to own the solution to her safety problem. On the basis of her FMEA alone, she should be able to craft and impose safety requirements for management’s consideration.
In Shook’s keynote, he asks the audience, “How does your organization think about problems? …having them? …finding them? …dealing with them? Are they bad things people want to hide – and honestly that’s a lot of what I see” [1]. It is counter intuitive and counter cultural if it is the engineer’s job to make great products, to raise her hand and say her product is a safety risk. It stops development in its tracks and certainly gets the attention of management. But isn’t that exactly what we want? Please pardon the pun, but I could go on Andon.
Almost any FMEA can be a framework for learning and seeing problems. The difference between a wasteful FMEA and a lean FMEA is the power to make immediate improvements directly in the FMEA, based on real updates to the product. This means giving the engineer authority to impose requirements on the rest of the organization.
When it comes to safe product development, both Silicon Valley and Detroit are less competitors and more colleagues, learning the same effective processes together with the global auto and tech industries. If safety means leaner, and I argue that it does, then everyone goes home a winner.
[1] Learn from John Shook, who was the first American manager at Toyota’s operations in Japan! You’ll hear why Lean leadership is the key in implementing Lean methodologies successfully. During this keynote, Shook demonstrates how to spread the Lean culture throughout your organization, and why you as a leader are responsible for Lean’s success or failure.
