Research and Development Process - Where does research end and development begin?

M

mshell

:frust:

Can someone please give me your opinion as to where the research portion of research and development ends and the development portion begins. It seems that we have several R&D employees that do not feel that ISO pertains to their function and I need a little help clarifying this issue.
 
Help us, define research at your co. a little better. I find everyone here goes back to the standard for reference. "Research" appears once in 9000, twice in 9004, but not at all in the 9001 requirements.

At my co., we start with a Design and Development plan from the beginning. Resources must be provided to investigate (research) the feasibility of a given idea. This may or may not convert into a product development project. For example, if we design and prototype a circuit board and find that we cannot meet the customer requirements for size or cost even though we meet the function spec., dead project. However, if this "research" proves a viable product, all of the information gathered becomes the foundation for the entire design-develop-manufacture-finished product-delighted customer process.

I would argue that you should have a business management system that would prevent wasting resources on researching impossible or impractical products.
 
M

mshell

It is the opinion of others that research is not completed until the product is production ready and you are able to produce parts for customer sampling. We have used multiple resources on the project and actually produced acceptable parts however, we have not perfected the process. The Research Team is saying that they are still in research phase but I think that once your deem the project as feasible, Design & Development should begin.(Am I just way off?)
 
Ouch!

mshell,
That's a little nutty! Our process starts at Section 7.2, determination of requirements. Why would you start researching something without knowing if there is a market?

Our very first engineering prototypes are built from engineering created drawings, engineering specified parts (purchased through our standard system by the materials dept.), with production personnel and tooling. Man oh man, you are way past research when you are producing parts for customer sampling. BTW, that is called Design and Development Validation and is section 6 of 7 in the 9k2k Design and Development section.
mshell said:
The Research Team is saying that they are still in research phase but I think that once your deem the project as feasible, Design & Development should begin.(Am I just way off?)
I would back up another step and say it starts just after you have defined what the (customer desired) end result would be. Feasibility studies (research) should be based on determining the capability to meet a defined requirement.
 

howste

Thaumaturge
Trusted Information Resource
Maybe I just don't get it, but why would it matter where exactly one ends and the other begins? Wouldn't you want to have an effective process to ensure that you get the results you want anyway? It sounds like maybe someone's afraid of being audited? I'm sure that research is an input to the design & development process and will probably be audited as such anyway...
 
Another nail driver

howste,
I think you've hit it! I have heard this one, "If you put all this ISO process control stuff into Engineering you'll take away their creativity and they won't be able to design anything."
Yes, I wan't to take away their creativity to spend untold resources researching products that are not viable, to generate undocumented designs, to generate untested designs, to generate designs that manufacturing does not have the equipment to produce, to generate designs that do not meet customer requirements, to make undocumented changes to products...."
 
Icy Mountain said:
Yes, I wan't to take away their creativity to spend untold resources researching products that are not viable, to generate undocumented designs, to generate untested designs, to generate designs that manufacturing does not have the equipment to produce, to generate designs that do not meet customer requirements, to make undocumented changes to products...."

Right on the button, Ice :agree:

Creativity is all to often interpreted as something that suffer from any form of control or rules. That is not the case at all. Creativity needs to be carefully aimed in the right direction if it is to prove useful.

/Claes
 
R

Raptorwild

Hello,
The very first thing that needs to be clarified to the R&D employees is that ISO pertains to every employee, period! As long as they keep notes of the actual research and development that is IMHO objective evidence that it is being done. I would ask them if they know how the Company's Quality Objectives pertain to their job and if they dont know...spell them out for them. :) Paula

mshell said:
:frust:

Can someone please give me your opinion as to where the research portion of research and development ends and the development portion begins. It seems that we have several R&D employees that do not feel that ISO pertains to their function and I need a little help clarifying this issue.
:bigwave:
 
M

mshell

Re: Research & Development

Thanks to all for your feedback. We have already included feasibility in our Sales Quote process as a requirement prior to submitting a quote to the customer however, this project started a LONG time ago and it is still on-going. As I am new to the organization, I just found out about it and the desire to exclude certain projects from Design & Development. It seems that our Product Development Manager worked for an organization that had little exclusions even though they were ISO certified and it is my understanding that she would like to do the same thing here. I am going to make it perfectly clear that any research project performed by the organization must be documented regardless of the success or failure of the said project. It only makes sense to track successes and failures for future reference.
 
Excellent!

mshell said:
It only makes sense to track successes and failures for future reference.
I think that is a great idea. I know this is the ISO forum not QS but I have an APQP Requirement for a customer whose last section under Process Review Managment and Continuous Improvement contains this output requirement: Corrective Action Plan, focusing on improvement of the product/process development cycle. This is one of those great things that also helps your business and meets a std. at the same time. Imagine reduced Eng. overhead due to an elimination of research that does not result in profitable products. Before I get slammed, I do believe that companies should have a certain amount of development that is a "failure" from the profit motivated side. Otherwise, you are not taking calculated risks to stretch your capabilities. However, it is important to learn from your mistakes. I am very good at this :biglaugh:
 
Top Bottom