We continue the exploration of the Poka Yoke post.  In the last post we discovered in building the product (late iteration) we have found that building the product has some undue complexity.  Upon further exploration we find that the design engineers suggested spending some time to Poka Yoke these devices.  The project hierarchy decided to not spend the time and money.  So…….

Now it has become apparent that building this product in customer volumes, in a manufacturing facility with strict time constraints to build and revulsion of rework required some alteration.  It is too late to “add” this scope to the project, so instead, another project is spawned to adjust the design to address this easy to build incorrect concern.  This subsequent project will not be available at the start of production.

How is this solution better than addressing the issue in the original project?  There will likely be miss builds of the product that will require dis-assembly to fix, just as this early system  required.  It should not be that we must see the failure –some of these things are able to be predicted? In this case it was.  Proof of failure is not always the best way to approach these problems. Perhaps we should thoughtfully consider the risks and take appropriate actions.  

In this case we did not have time to do it right, but we had time to do it twice.