3
$\begingroup$

Within most engineering development processes, product testing and validation is an integral part of the product development process.

All prototype / engineering development samples are tested. And all failures are handed over to product engineering with failure reports, which includes test data documented in various forms (paper, word documents, excel tables, etc). The product development team then gets 1-2 weeks to perform root cause analysis and develop corrective action before the product goes into production.

The current root cause analysis / corrective action process that I'm working with can be characterized at best as chaotic, brute force, or uncoordinated. Needless to say, some product comes back as warranty returns or field returns. We'd like to drive the return rate down.

The business conditions, competition, and resource levels don’t permit the luxury of additional time for root cause analysis and proper (the way I prefer) corrective action. We do understand there are areas in the engineering development process that can be improved, and plans are underway to implement these improvements. Currently, we are following waterfall project management methodology. And it's worth noting that I am responsible for the electrical engineering component only.

Question: What is an engineering product develop process strategy that will help bring order to the current chaotic, brute force, uncoordinated root cause analysis and corrective action processes?

We currently have a few suggestions on the table, but would like to probe the community for additional insight.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ I think you're getting lost in your own overly-generic language. Can you be more specific? There's no generic method for finding the root cause of a failure; each one must be analyzed on its own. $\endgroup$
    – Dave Tweed
    Jan 23, 2015 at 3:04
  • $\begingroup$ @DaveTweed, I think there are engineering management techniques to effectively organize and manage large engineering problems. $\endgroup$
    – Mahendra Gunawardena
    Jan 25, 2015 at 11:54
  • 1
    $\begingroup$ Sounds like a job for an Expert System based on a specialized event correlator. These two keywords should give you a point of start into the ocean-sized domain dedicated to these problems. (currently at my job, I'm at attempt#8 to develop one... Browse my questions on Programmers.SE for some problems that occurred while developing (currently abandoned) attempt#7.) $\endgroup$
    – SF.
    Feb 6, 2015 at 9:58
  • $\begingroup$ @SF sorry I don't totally Understand your comment. Can please attach a link the comment on Programmers SE $\endgroup$
    – Mahendra Gunawardena
    Feb 6, 2015 at 12:26
  • $\begingroup$ 1, 2, 3, and also from SO: 4 5 - none of these solve your problem, but they should give you a taste of what you're facing. $\endgroup$
    – SF.
    Feb 6, 2015 at 12:44

1 Answer 1

Reset to default
5
$\begingroup$

Generically speaking, the first step would be to determine if your failures have any factors in common. You could also examine your successes and see if they have anything in common. These commonalities could be things such as the employee working on the product, location where the tests were performed, specific piece of equipment on which the tests were performed, time of day, etc. Once you have identified some commonalities you can attempt to determine if any of them are the proximate cause of the failures and work backwards until you can determine the ultimate cause.

Of course, the details of how to do this depend on the details of your situation.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.