Blog

Poke Yoke


Poke Yoke

Jon M Quigley

There are a set of tools and techniques that come with developing products for the automotive industry and are part of the Advanced Product Quality Planning for the product.  We have written about APQP or some years and have decades of experience in this approach to product development.  In general, the phases of the project are described as:

Voice of Customer Product Development Process Development Product Validation Process Validation Launch Feedback

 

 

We have a discussion board that supports questions you may have regarding APQP.  Today, we will ruminate on the technique known as Poke Yoke, which I heard an Supplier Quality Assurance professional refer to as “goof proofing”.  While largely benefiting manufacturing, these considerations and implementation is achieved in the development work, otherwise we end up doing considerable rework of the developed product to optimize manufacturing or field service work. Rather, we will use design for manufacturing (DFM) or design for … Continue reading


Expectations of Contractors and Engineers


Expectations of Contractors and Engineers Written by Steven G. Lauck & Jon M. Quigley

To ensure the team is working from the same set of expectations, we may develop a document or set of documents that describe those expectations. The work below may help you set up your own documentation on the expectations you have of your team and reciprocally what they will have of you.

The file below is found as a download here.

I. Focus Areas Customer/Supplier Orientation

Understand who your customers are and how well your products and services are meeting their needs. Adopt the posture of evaluating the quality and value of your services periodically as a basis for continual improvement.

Mastery

Be a master of the position functions and establish yourself as a resource to others. Know what your products and services are and strive to be best in delivering them.  Epitomize continuous learning and bring that to your work life.

Organization

Support … Continue reading


One Throw-Away Product – Or Refactoring


I have been speaking at many PMI chapter events in North Carolina this year. I enjoy doing these events, meeting new people, discussing different and new things, and sometimes, being introduced to cool old things.  One such event was the PMI Asheville Chapter where I met some really interesting people including Eric W.

Mythical Man Month

 

 

Eric is a software person, he writes code and in our conversation at the meeting (the topic was risk and risk management) it became clear he is also one of those that have been around software development for years. Shortly after that meeting I received a package via amazon from Eric W, the book, The Mythical Man Month.  This book is interesting for several reasons, not the least of which is it was written by a North Carolinian, or at least a professor at North Carolina University.

This is an old book, from the 1970’s and I … Continue reading


Missing Requirements


Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  … Continue reading


Let’s Dump the Product Demonstration – Because we are Agile.


It is clear to me that some people think an agile approach means you can willy-nilly delete things in the process. This is also true for conventional project, but I do not think for the same reasons. For conventional projects, it seems time pressures cause elimination of certain functions or processes to keep the schedule. For agile, again no study but based on observed discussions, the elimination seems to be because there is no doctrine or perceived process that is required to be adhered.  This means things can be arbitrarily altered or changed, or even eliminated. That is certainly true, but you must consider the consequences of not performing the activity (for example product demonstration)?  From my perspective, there is a balance between adherence to a process (repeatable and baseline for learning  ) and adapting to the circumstances.

What does this product demonstration do, can I eliminate it, and what will likely be the consequences?

For the record, I am … Continue reading


Why formalize root cause analysis?


Why formalize root cause analysis?

 

There are many approaches to determining the root of our problems.  In the automotive world, there are two typical approaches, the 8D or the 8 Discipline, or the A3 (named for the paper size).  We will not go into the details of either of these approaches but you can find the templates for these by clicking the links above.

There are some benefits to a formalized root cause analysis.  We can think of 6 reasons as listed below:

Controls jumping to conclusions and just working on the symptom Repeatable Coordinates effort / focus Documents actions so we know what have tried and what is next Traceable for future events

 

 

Controls jumping to conclusions and just working on the symptom

A formalized approach to root cause analysis in such a way that will keep us from jumping to conclusions about the nature of the failure.   Those that have read this … Continue reading


Communication and distribution of work


Communication and Project Team Distribution

There are times when our business does not have all the requisite talent within the walls of the organization. It is nearly impossible to be fully prepared for every opportunity available, and the business and time investment in expertise that is only transitory seldom passes muster. However, when we build this network of internal and external or numerous external sites, we must also consider the communications that will vary depending upon the scope of the project. Let’s consider a company is building the network that consist of three companies:

The development Test and verification Our organization (UAT)

Immediately after the articulation of the project scope, we need to identify the players and areas of responsibility. Our communications planning should account for the distribution of the work, and so too our schedule. We must account for the transitions between the organizations, who needs what information and what constitute good quality of information as well as good … Continue reading


Page 1 of 6412345...102030...Last »
Single Sign On provided by vBSSO