The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Feasibility Evaluation - Product Adequately Defined?


Lewis
8th April 2005, 03:45 PM
I need some assistance with regards to performing a manufacturing feasibility and risk assessment to meet paragraph 7.2.2.2 of the TS 16949:2002 standard. First, my organization has adopted a version of the Team Feasibility Commitment form referenced in the back of the APQP manual. The first question on this form states: "Is product adequately defined (application requirements, etc.) to enable feasibility evaluation?"

Question #1: Is the intent of this first question to assess whether or not our organization knows the use of ( or end use of) the product by our customer?

Question #2: I contend that our organization should be able to alter (i.e. re-word) the questions as necessary to fit our manufacturing processes, as long as the intent of the issues remains. Is this true?

db
8th April 2005, 04:04 PM
Question #1: Is the intent of this first question to assess whether or not our organization knows the use of ( or end use of) the product by our customer?
The first question just means that you need to have ALL the information required to determine feasibility.


Question #2: I contend that our organization should be able to alter (i.e. re-word) the questions as necessary to fit our manufacturing processes, as long as the intent of the issues remains. Is this true?
Unless specified by the customer, you are not required to use the form. Therefore, if changing the form makes sense, then change it. One caution here. Don’t make changes so you don’t have to take the steps to do a proper study – that will just end in disaster.

Lewis
8th April 2005, 04:15 PM
So if the answer is "No" to the first question, there is no need to proceed further with the rest of the questions since we don't have ALL of the information. Is this correct?
My only concern with this is that the customer seldom provides ALL of the information in a timely manner. That shouldn't hold up progress on the development of a project, nor the need to address the rest of the issues.

Please excuse my lack of understanding.

db
8th April 2005, 04:34 PM
So if the answer is "No" to the first question, there is no need to proceed further with the rest of the questions since we don't have ALL of the information. Is this correct?
My only concern with this is that the customer seldom provides ALL of the information in a timely manner. That shouldn't hold up progress on the development of a project, nor the need to address the rest of the issues.

Please excuse my lack of understanding.
If the answer is no on question # 1, then you cannot go any farther. For example, if I asked you how far it is from your house to downtown E-Town, you might be able to give me an answer. But if I asked how far from your house, to mine, you can't. If the customer doesn't give you all of the information, you might have to go with what you do have. Also, take into account the customer and the relationship you have.

Lewis
8th April 2005, 06:45 PM
For new customers, we've yet to build a relationship with them. I guess the best way to proceed is that if we feel that we don't have all of the information, then we should just go ahead and complete the feasibility and risk assessment as best as we can and request the information from the customer.
If we answer "no" to the first question and then stop, that may hold up progress on the rest of the issues. It is highly unlikely that we're ever going to say no to the project.

Jim Wynne
8th April 2005, 06:59 PM
I think DB's answers thus far are right on the money. Don't let the tail wag the dog. Your main focus should be on preparedness of your own processes, rather than end use of the product. That's the customer's concern, and it should be adequately expressed in the specifications. You should stop, however, if you reach a point where lack of specifications means you have to start guessing. Make sure that the customer understands that your company's timeliness depends on theirs.

Caster
9th April 2005, 04:58 PM
[QUOTE=Lewis]So if the answer is "No" to the first question, there is no need to proceed further with the rest of the questions since we don't have ALL of the information. Is this correct?
My only concern with this is that the customer seldom provides ALL of the information in a timely manner. That shouldn't hold up progress on the development of a project, nor the need to address the rest of the issues.
QUOTE]

My 2 cents here. As long as you create an open item (or what ever you call it) you can keep going. Just make sure that you keep coming back to review the open item and press them to get the information.

All projects seem to be fast tracked these days. The good news with inadequately defined customer requirements is that any late breaking requirements become changes and you can try to get more time or money.

Like you say, you're going to do this project anyway, don't let the system tie your hands or it won't get used.

Hey, the shuttle is on the pad and they're still working open items. If it's good enough for NASA it's good enough for me.

shudy
12th April 2005, 03:07 AM
hi..
i have a question about ts16949 so may be you can help me to explain more detail.So the question is i want know what should i have the procedure in ts 16949....
Please excuse my lack of understanding.[/QUOTE]

Icy Mountain
20th April 2005, 04:59 PM
The first question just means that you need to have ALL the information required to determine feasibility.


Unless specified by the customer, you are not required to use the form. Therefore, if changing the form makes sense, then change it. One caution here. Don’t make changes so you don’t have to take the steps to do a proper study – that will just end in disaster.
Careful, db. I just got dinged in a Pre-Audit for a lack of things on proper forms, even though the information was available, if not necessarily on the proper forms. I would argue this finding vehemently in a registration audit, though.