RE: Quality Assurance and Product Approvals
Interesting thread . . . At the companies for which I managed the regulatory programs over the last 20 years, it has always been engineering's responsibility to release to production a compliant product,and I have always been a member of the engineering department. In the early days, before regualtory compliance became the industry that it is now, it was basically 'putting out the fires' after formal evaluation. After a couple of costly rework projects, 'design for compliance' became my mantra, and I have been able to carry that along to other companies as well. And fortunately for me, it has been well received. As part of the design team, I am able review all product designs before and during the prototype stage and provide guidance/input as necessary. Each time I announce that the product passed the first time (don't get me wrong, I do have the occassional 'gotcha') it gets easier to justify the 'design for compliance' concept. It's a lot more difficult to cost-effectively rework a product. So, besides making my job easier (and the cognizant design engineer's as well), 'design for compliance' does save costs in the long run. Additionally, as part of the corporation's quality team providing the opportunity to ensure continued compliance. John Juhasz Fiber Options Bohemia, NY -Original Message- From: Tania Grant [mailto:taniagr...@msn.com] Sent: Wednesday, November 28, 2001 11:15 PM To: John Woodgate; emc-p...@majordomo.ieee.org Subject: Re: Quality Assurance and Product Approvals My personal experience agrees with John. I prefer to work with Engineering and reporting someplace in Engineering;-- it makes my job easier when compliance is "designed" right from the very beginning rather than be responsible later to get it past agencies. At that point, it suddenly became my "problem" when it did not comply! When I told management that they should fix things before we submitted the product formally, the response was "let's see what the agency will do" This left me frustrated and embarrassed my ego. If you catch things in the very beginning, engineering is usually amenable to changing things. Later, it is very difficult and, obviously, much more costly. taniagr...@msn.com <mailto:taniagr...@msn.com> - Original Message - From: John Woodgate Sent: Wednesday, November 28, 2001 2:48 PM To: emc-p...@majordomo.ieee.org Subject: Re: Quality Assurance and Product Approvals I read in !emc-pstc that Mark Werlwas wrote (in <006701c1782b$69f56020$6401a...@frmt1.sfba.home.com>) about 'Quality Assurance and Product Approvals', on Wed, 28 Nov 2001: >On the aspect of the "where to put Product Safety/Compliance in the >organization" discussion bears mentioning on the forum. In general I >advocate that the Product Safety/Compliance department be separate from >Engineering, Sales, and Operations. The Safety/Compliance group should avoid >conflicts of interest (real or apparent) that may arise in the above >mentioned groups. Even the occasional appearance of a conflicting interest >can undermine the credibility of the Safety/Compliance team. But this militates strongly against 'designing-in compliance', and is very liable to create a 'them and us' conflict between Design Engineering and Compliance. The *maintenance* of compliance in manufacture is a Quality function. -- Regards, John Woodgate, OOO - Own Opinions Only. http://www.jmwa.demon.co.uk After swimming across the Hellespont, I felt like a Hero. --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and Product Approvals
Hi All, When I was with Xerox, Versatec Division, we were placed in the Engineering Services Dept. with Drafting and Component engineering. This worked very well and gave us input to the purchasing specifications as well as design considerations. Our relationship with Engineering was very good, with our manager sitting on the change review and material review boards. We reported ultimately to a Director of Engineering Services (and a good Director if you are out there Joyce), but not a VP. Scott leeschm...@aol.com wrote: > Hi all, > > Interesting discussion. Here is my 2 cents. Must be about $1.00 worth by > now. > > I once came upon an interesting compromise as to the organization chart > position of compliance. They put it in test or quality, but funded it > through the engineering budget. Not perfect, but it prevented engineering > from squeezing the last 0.5 dB or hi pot voltage from the device. However it > does encourage them to save money and design in compliance. > > I suppose in the best of all possible worlds this would not be necessary but > it did seem to work. A VP of compliance is probably work the best, of course > if they chose me for the position. > > Lee Schmitz > Electrical safety compliance consultant > > --- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Michael Garretson:pstc_ad...@garretson.org > Dave Healddavehe...@mediaone.net > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > Jim Bacher: j.bac...@ieee.org > > All emc-pstc postings are archived and searchable on the web at: > No longer online until our new server is brought online and the old > messages are imported into the new server. --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and Product Approvals
Hi all, Interesting discussion. Here is my 2 cents. Must be about $1.00 worth by now. I once came upon an interesting compromise as to the organization chart position of compliance. They put it in test or quality, but funded it through the engineering budget. Not perfect, but it prevented engineering from squeezing the last 0.5 dB or hi pot voltage from the device. However it does encourage them to save money and design in compliance. I suppose in the best of all possible worlds this would not be necessary but it did seem to work. A VP of compliance is probably work the best, of course if they chose me for the position. Lee Schmitz Electrical safety compliance consultant --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and Product Approvals
My personal experience agrees with John. I prefer to work with Engineering and reporting someplace in Engineering;-- it makes my job easier when compliance is "designed" right from the very beginning rather than be responsible later to get it past agencies. At that point, it suddenly became my "problem" when it did not comply! When I told management that they should fix things before we submitted the product formally, the response was "let's see what the agency will do" This left me frustrated and embarrassed my ego. If you catch things in the very beginning, engineering is usually amenable to changing things. Later, it is very difficult and, obviously, much more costly. taniagr...@msn.com - Original Message - From: John Woodgate Sent: Wednesday, November 28, 2001 2:48 PM To: emc-p...@majordomo.ieee.org Subject: Re: Quality Assurance and Product Approvals I read in !emc-pstc that Mark Werlwas wrote (in <006701c1782b$69f56020$6401a...@frmt1.sfba.home.com>) about 'Quality Assurance and Product Approvals', on Wed, 28 Nov 2001: >On the aspect of the "where to put Product Safety/Compliance in the >organization" discussion bears mentioning on the forum. In general I >advocate that the Product Safety/Compliance department be separate from >Engineering, Sales, and Operations. The Safety/Compliance group should > avoid >conflicts of interest (real or apparent) that may arise in the above >mentioned groups. Even the occasional appearance of a conflicting interest >can undermine the credibility of the Safety/Compliance team. But this militates strongly against 'designing-in compliance', and is very liable to create a 'them and us' conflict between Design Engineering and Compliance. The *maintenance* of compliance in manufacture is a Quality function. -- Regards, John Woodgate, OOO - Own Opinions Only. http://www.jmwa.demon.co.uk After swimming across the Hellespont, I felt like a Hero. --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and Product Approvals
I read in !emc-pstc that Mark Werlwas wrote (in <006701c1782b$69f56020$6401a...@frmt1.sfba.home.com>) about 'Quality Assurance and Product Approvals', on Wed, 28 Nov 2001: >On the aspect of the "where to put Product Safety/Compliance in the >organization" discussion bears mentioning on the forum. In general I >advocate that the Product Safety/Compliance department be separate from >Engineering, Sales, and Operations. The Safety/Compliance group should > avoid >conflicts of interest (real or apparent) that may arise in the above >mentioned groups. Even the occasional appearance of a conflicting interest >can undermine the credibility of the Safety/Compliance team. But this militates strongly against 'designing-in compliance', and is very liable to create a 'them and us' conflict between Design Engineering and Compliance. The *maintenance* of compliance in manufacture is a Quality function. -- Regards, John Woodgate, OOO - Own Opinions Only. http://www.jmwa.demon.co.uk After swimming across the Hellespont, I felt like a Hero. --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
RE: Quality Assurance and Product Approvals
Maybe this problem is even more insidious: Ask your HR department if they have a "Radford Benchmark Salary Survey" Job Description -for the work you do. (or equivalent to AON Consulting/Radford Associates service) I became aware some months ago that in some parts of the industry do not have a job description for the product safety functionary!! Maybe RBSS is unique in this, or my case is unusual, but the closest they could come for me was job code 8284 "Software Technician 4". Beyond the 'specialist' level...there should be an 'esoteric level'.. heh, heh -obviously this is not close- So I've been listing what it is that I do. I'm up to 4 pages so far... Kyle MOO!
Re: Quality Assurance and Product Approvals
> On the aspect of the "where to put Product Safety/Compliance in the > organization" discussion bears mentioning on the forum. In general I > advocate that the Product Safety/Compliance department be separate from > Engineering, Sales, and Operations. The Safety/Compliance group should > avoid conflicts of interest (real or apparent) that may arise in the > above mentioned groups. Even the occasional appearance of a conflicting > interest can undermine the credibility of the Safety/Compliance team. Over the years, I've been a member of various organizations, but always doing the same function (job). Regardless of organization, I did the same job. I've found that my effectiveness in doing the job is much better when I have been physically close to the R&D teams. Likewise, I've found that my effectiveness in doing the job is much better when I have been a part of the same organization as R&D. I've always taken the approach that safety is designed into the product from the very start of the project. Safety is an engineering discipline that, unfortunately, is not a part of engineering school curricula. So, it must be learned on the job, and I am the teacher. The R&D engineer is responsible for designing the safety of the product; I am the consultant who explains the safety function, offers examples of acceptable designs, provides criteria for acceptable designs, evaluates and tests proposed designs, and ultimately agrees that the specific design meets the safety function requirement. Its a team effort. Credibility and expertise of the safety engineer is a key element to being accepted as a part of the team. Externally imposed organizational requirements that the Product Safety group be organizationally positioned to avoid "conflict of interest" seem to presuppose a management style and philosophy that I have not experienced. (I'm sure I've lived a sheltered life in terms of management style and philosophy!) :-) In an ideal world, the R&D engineer would be trained in product safety. There would be no need for the product safety engineer I've described above. Safety testing would be included in the product functional testing, not as a separate entity. Third-party certifications would be obtained by a procurement group (charged with buying the right to use the mark). Best regards, Rich --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
RE: Quality Assurance and Product Approvals
Charles, Yup, I knew that. I think that Dell recognizes that the whole compliance picture involves more than just getting some certification marks slapped on the product. Daniel E. Teninty, P.E. Managing Partner DTEC Associates LLC Streamlining The Compliance Process Advancing New Products To Market http://www.dtec-associates.com (509) 443-0215 (509) 443-0181 fax -Original Message- From: Charles Grasso [mailto:chasgra...@hotmail.com] Sent: Wednesday, November 28, 2001 9:33 AM To: dteni...@dtec-associates.com; ri...@sdd.hp.com; nutwoo...@nutwood.eu.com Cc: emc-p...@majordomo.ieee.org Subject: RE: Quality Assurance and Product Approvals One comment on the VP for compliance.. It is my undersyand that the Dell VP position does ALL the functions that are imposed by legislation on a compamy. EMC is one part. There is of course Safety, Environmental Issues, Lead-free solder etc.. Dell is taking a very professional approach to addresses ALL the issues - not just EMC. >From: "Dan Teninty" >Reply-To: "Dan Teninty" >To: "Rich Nute" , >CC: >Subject: RE: Quality Assurance and Product Approvals >Date: Tue, 27 Nov 2001 01:24:35 -0800 > > >Rich, > >Dell Computers, as well as a few other major players, take a proactive >approach to compliance and actually have a VP position for compliance. With >a little investigation into the benefits of having a first rate compliance >department with the ability to design for compliance, test to relevant >standards, compile reports, participate on standards committees, and deal >directly with world wide agencies I would think that most companies that >have global markets would see both the short term and long term benefits to >the bottom line. I would tend to include PC's into the ordinary products >pile, wouldn't you? > >Companies that choose to take the adversarial approach to compliance by >cutting corners or only doing the minimum to comply, save dollars in the >short term, but pay later in lost customers, or worse, lawsuits. One of our >clients, had a management team that took this denial/avoidance approach to >NEBS. When the Telecom downturn came, they were left in a position where >there was lots less demand and what demand there was, was for NEBS >compliant >products. Most of the management team that made those decisions have either >left the company in recent right-sizing exercises, or are working in lesser >positions. > >It seems that hindsight is always able to find a goat. When I explain the >benefits of compliance to management teams, I try to focus on the bottom >line benefits of having a product that is marketable everywhere. The costs >for compliance, when compared to the total development cost for a new >product tend to be in the noise. If these costs are amortized over >reasonable quantities, then the unit cost for compliance tends to be a >bargain. > >Its not hard to dig up a few good case studies in Product Liability to >drive >home the point. > >Best regards, > >Daniel E. Teninty, P.E. >Managing Partner >DTEC Associates LLC >Streamlining The Compliance Process >Advancing New Products To Market >http://www.dtec-associates.com >(509) 443-0215 >(509) 443-0181 fax > >-Original Message- >From: owner-emc-p...@majordomo.ieee.org >[mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Rich Nute >Sent: Monday, November 26, 2001 12:36 PM >To: nutwoo...@nutwood.eu.com >Cc: emc-p...@majordomo.ieee.org >Subject: Re: Quality Assurance and Product Approvals > > >Hi Alan: > > > Two questions, does the group see a time when we have a VP Compliance >on > > level terms with VP Finance, VP Marketing etc, or is this already > > happening in the US. > >No. And not likely to happen in companies with ordinary >products. > >As a general rule, "compliance" is seen as a necessary >evil. It is a cost without an associated revenue (or >customer-recognized need or benefit). Few companies >want to give VP status (and an empire) to a non-revenue- >generating function. > >Many companies measure the product incremental cost for >"compliance." The objective is to find methods and means >for minimizing these product costs. > >Furthermore, few companies recognize the work of "compliance" >folks as prevention of future unanticipated costs such as >failure of sales due to non-compliance, product liability, >or even product recalls. The reason the work is not >recognized is the difficulty of measuring the future cost of >non-compliance, especially if the company has never had such >an incident. > > > Second Question. Does the group think a formal qualification in > > Compliance Management & CE Markin
RE: Quality Assurance and Product Approvals
One comment on the VP for compliance.. It is my undersyand that the Dell VP position does ALL the functions that are imposed by legislation on a compamy. EMC is one part. There is of course Safety, Environmental Issues, Lead-free solder etc.. Dell is taking a very professional approach to addresses ALL the issues - not just EMC. From: "Dan Teninty" Reply-To: "Dan Teninty" To: "Rich Nute" , CC: Subject: RE: Quality Assurance and Product Approvals Date: Tue, 27 Nov 2001 01:24:35 -0800 Rich, Dell Computers, as well as a few other major players, take a proactive approach to compliance and actually have a VP position for compliance. With a little investigation into the benefits of having a first rate compliance department with the ability to design for compliance, test to relevant standards, compile reports, participate on standards committees, and deal directly with world wide agencies I would think that most companies that have global markets would see both the short term and long term benefits to the bottom line. I would tend to include PC's into the ordinary products pile, wouldn't you? Companies that choose to take the adversarial approach to compliance by cutting corners or only doing the minimum to comply, save dollars in the short term, but pay later in lost customers, or worse, lawsuits. One of our clients, had a management team that took this denial/avoidance approach to NEBS. When the Telecom downturn came, they were left in a position where there was lots less demand and what demand there was, was for NEBS compliant products. Most of the management team that made those decisions have either left the company in recent right-sizing exercises, or are working in lesser positions. It seems that hindsight is always able to find a goat. When I explain the benefits of compliance to management teams, I try to focus on the bottom line benefits of having a product that is marketable everywhere. The costs for compliance, when compared to the total development cost for a new product tend to be in the noise. If these costs are amortized over reasonable quantities, then the unit cost for compliance tends to be a bargain. Its not hard to dig up a few good case studies in Product Liability to drive home the point. Best regards, Daniel E. Teninty, P.E. Managing Partner DTEC Associates LLC Streamlining The Compliance Process Advancing New Products To Market http://www.dtec-associates.com (509) 443-0215 (509) 443-0181 fax -Original Message- From: owner-emc-p...@majordomo.ieee.org [mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Rich Nute Sent: Monday, November 26, 2001 12:36 PM To: nutwoo...@nutwood.eu.com Cc: emc-p...@majordomo.ieee.org Subject: Re: Quality Assurance and Product Approvals Hi Alan: > Two questions, does the group see a time when we have a VP Compliance on > level terms with VP Finance, VP Marketing etc, or is this already > happening in the US. No. And not likely to happen in companies with ordinary products. As a general rule, "compliance" is seen as a necessary evil. It is a cost without an associated revenue (or customer-recognized need or benefit). Few companies want to give VP status (and an empire) to a non-revenue- generating function. Many companies measure the product incremental cost for "compliance." The objective is to find methods and means for minimizing these product costs. Furthermore, few companies recognize the work of "compliance" folks as prevention of future unanticipated costs such as failure of sales due to non-compliance, product liability, or even product recalls. The reason the work is not recognized is the difficulty of measuring the future cost of non-compliance, especially if the company has never had such an incident. > Second Question. Does the group think a formal qualification in > Compliance Management & CE Marking would be a good idea. While we may think this is a good idea, most professional managers in the field of compliance consider the job as one interim step in their career. If "compliance" is a non- revenue-generating activity, then the step to personal growth is to measure the cost of compliance for the duration of one's leadership, and add this to one's CV. Then, move on. Candidates for compliance management might find courses useful. However, the value of such qualifications is not for the long term. Another problem is that upper management doesn't want to be told that they are restricted by compliance rules insofar as setting objectives for the products and the company. They certainly don't want to feel that the only management folks qualified for managing a compliance function are those that are trained and qualified in compliance management. Formal qualification in compliance management may be seen by upper management as a power play where the compliance manager uses h
Re: Quality Assurance and Product Approvals
On the aspect of the "where to put Product Safety/Compliance in the organization" discussion bears mentioning on the forum. In general I advocate that the Product Safety/Compliance department be separate from Engineering, Sales, and Operations. The Safety/Compliance group should avoid conflicts of interest (real or apparent) that may arise in the above mentioned groups. Even the occasional appearance of a conflicting interest can undermine the credibility of the Safety/Compliance team. One of the valuable services that the Safety/Compliance group can provide the company is an independent assessment of a risk, hazard, situation, etc. My previous company had Safety/Compliance located with Quality. There are many overlapping and similar functions between the groups such as auditing compliance, training teams, influencing business processes, managing change control, responding to customers... -Mark Werlwas - Original Message - From: Alan E Hutley To: emc-pstc discussion group Sent: Thursday, November 22, 2001 12:40 AM Subject: Quality Assurance and Product Approvals Hi All I have been following with great interest the detailed and in-depth responses to this topic. I have noted that particularly in Europe as the list of New Approach Directives and other regulations grow, plus Safety and Quality issues, that companies are divesting more importance to this whole area. Two questions, does the group see a time when we have a VP Compliance on level terms with VP Finance, VP Marketing etc, or is this already happening in the US. Second Question. Does the group think a formal qualification in Compliance Management & CE Marking would be a good idea. It seems amazing that considering the importance and complexity of this area there is not as yet one qualification that can prove a persons competence. At least in Europe I am not sure about the US and rest of the world. Any comments please. Alan E Hutley Editorial & Publishing Director EMC Compliance journal www.compliance-club.com
Re: Quality Assurance and Product Approvals
Hi Dan: > Dell Computers, as well as a few other major players, take a proactive > approach to compliance and actually have a VP position for compliance. With > a little investigation into the benefits of having a first rate compliance > department with the ability to design for compliance, test to relevant > standards, compile reports, participate on standards committees, and deal > directly with world wide agencies I would think that most companies that > have global markets would see both the short term and long term benefits to > the bottom line. I would tend to include PC's into the ordinary products > pile, wouldn't you? I do agree with (and we practice) a pro-active approach to compliance. In my experience, though, I am surprised that a compliance manager would be a VP position (in a company making "ordinary products" as compared to a company making medical products or similar products subject to a high degree of regulation). As you mention, there can be short-term and long-term benefits to the compliance activities you mention. However, the benefits must outweigh the costs of the activities. Quantifying and measuring the benefits of some compliance activities is often very difficult. Management philosophy of the particular company is another significant variable in the extent of compliance activity. Some companies believe that safety certification is sufficient safety. Others believe that safety and safety certification are independent although overlapping activities. At one time, I knew of a company that addressed safety not in the product, but in liability avoidance through instruction manuals, through insurance, and by passing liability on to its suppliers. Cost effective, yes. Morally effective, questionable. > Companies that choose to take the adversarial approach to compliance by > cutting corners or only doing the minimum to comply, save dollars in the > short term, but pay later in lost customers, or worse, lawsuits. One of our > clients, had a management team that took this denial/avoidance approach to > NEBS. When the Telecom downturn came, they were left in a position where > there was lots less demand and what demand there was, was for NEBS compliant > products. Most of the management team that made those decisions have either > left the company in recent right-sizing exercises, or are working in lesser > positions. Reducing the cost of compliance does not in any way imply an adversarial approach to compliance. Neither does cost reduction imply a reduction in the compliance performance of the product. For example, some years ago a R&D engineer came to me and said, "The cost of safety is too high." My immediate response was, "Not if you design in safety from the start of the project." He replied, "No. I mean that safety requires me to use a power switch and a fuse. These cost money. The switch serves no benefit to the user since the unit is left on continuously." (This was back in the days when the plug was not considered a disconnect device.) So, I started a project to determine alternatives to switches and fuses and other safety components (for the specific products we were building at that time). In terms of EMC compliance, I know one engineer who keeps track of the number and cost of components used exclusively for EMC control. His objective was to reduce the total cost of EMC control. This in no way is cutting corners of compliance, or doing the minimum to comply. The result was still full compliance -- but at least cost. > It seems that hindsight is always able to find a goat. When I explain the > benefits of compliance to management teams, I try to focus on the bottom > line benefits of having a product that is marketable everywhere. The costs > for compliance, when compared to the total development cost for a new > product tend to be in the noise. If these costs are amortized over > reasonable quantities, then the unit cost for compliance tends to be a > bargain. There are two kinds of costs associated with compliance. The first kind is the cost of compliance in the product development. I agree that these costs are indeed "in the noise" compared to the overall development costs. The second kind of cost of compliance is the cost of labor and components that are installed solely for compliance. For high-volume products, these costs are far more important than the costs of development because they affect the price competitiveness of the product. A flame-retardant plastic costs more than a non-flame-retardant plastic. How can we design a product to minimize the use of flame-retardant plastic yet comply with the standards as well as being a truly safe product? For me, this second cost, the per-unit cost of compliance, is a very significant part of my job. Best regards, Rich --- This message is from the IEEE EMC So
Re: Quality Assurance and Product Approvals
I read in !emc-pstc that Dan Teninty wrote (in ) about 'Quality Assurance and Product Approvals', on Tue, 27 Nov 2001: > >Rich, > >Dell Computers, as well as a few other major players, take a proactive >approach to compliance and actually have a VP position for compliance. With >a little investigation into the benefits of having a first rate compliance >department with the ability to design for compliance, test to relevant >standards, compile reports, participate on standards committees, and deal >directly with world wide agencies I would think that most companies that >have global markets would see both the short term and long term benefits to >the bottom line. I would tend to include PC's into the ordinary products >pile, wouldn't you? > This is indeed the enlightened view. I started advocating this 30 years ago. It's been a long struggle. >Companies that choose to take the adversarial approach to compliance by >cutting corners or only doing the minimum to comply, save dollars in the >short term, but pay later in lost customers, or worse, lawsuits. One of our >clients, had a management team that took this denial/avoidance approach to >NEBS. When the Telecom downturn came, they were left in a position where >there was lots less demand and what demand there was, was for NEBS compliant >products. Most of the management team that made those decisions have either >left the company in recent right-sizing exercises, or are working in lesser >positions. Compliance with standards is now a regular customer demand, sometimes carried to excess, usually through lazily or ignorantly attempting to over-simplify the subject, e.g. 'All equipment used shall comply with all British, European and International standards'. > >It seems that hindsight is always able to find a goat. When I explain the >benefits of compliance to management teams, I try to focus on the bottom >line benefits of having a product that is marketable everywhere. The costs >for compliance, when compared to the total development cost for a new >product tend to be in the noise. If these costs are amortized over >reasonable quantities, then the unit cost for compliance tends to be a >bargain. I regard the cost of compliance as part of the costs of being present in the market, not as part of the cost of making a product that works. Seriously non-compliant product can still work. That way, you get to compare the cost of compliance with, for example, the cost of advertising or even the cost of participating in exhibitions. > >Its not hard to dig up a few good case studies in Product Liability to drive >home the point. > Indeed, and however circumspect everyone is, there is always a finite probability... -- Regards, John Woodgate, OOO - Own Opinions Only. http://www.jmwa.demon.co.uk After swimming across the Hellespont, I felt like a Hero. --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
RE: Quality Assurance and Product Approvals
Rich, Dell Computers, as well as a few other major players, take a proactive approach to compliance and actually have a VP position for compliance. With a little investigation into the benefits of having a first rate compliance department with the ability to design for compliance, test to relevant standards, compile reports, participate on standards committees, and deal directly with world wide agencies I would think that most companies that have global markets would see both the short term and long term benefits to the bottom line. I would tend to include PC's into the ordinary products pile, wouldn't you? Companies that choose to take the adversarial approach to compliance by cutting corners or only doing the minimum to comply, save dollars in the short term, but pay later in lost customers, or worse, lawsuits. One of our clients, had a management team that took this denial/avoidance approach to NEBS. When the Telecom downturn came, they were left in a position where there was lots less demand and what demand there was, was for NEBS compliant products. Most of the management team that made those decisions have either left the company in recent right-sizing exercises, or are working in lesser positions. It seems that hindsight is always able to find a goat. When I explain the benefits of compliance to management teams, I try to focus on the bottom line benefits of having a product that is marketable everywhere. The costs for compliance, when compared to the total development cost for a new product tend to be in the noise. If these costs are amortized over reasonable quantities, then the unit cost for compliance tends to be a bargain. Its not hard to dig up a few good case studies in Product Liability to drive home the point. Best regards, Daniel E. Teninty, P.E. Managing Partner DTEC Associates LLC Streamlining The Compliance Process Advancing New Products To Market http://www.dtec-associates.com (509) 443-0215 (509) 443-0181 fax -Original Message- From: owner-emc-p...@majordomo.ieee.org [mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Rich Nute Sent: Monday, November 26, 2001 12:36 PM To: nutwoo...@nutwood.eu.com Cc: emc-p...@majordomo.ieee.org Subject: Re: Quality Assurance and Product Approvals Hi Alan: > Two questions, does the group see a time when we have a VP Compliance on > level terms with VP Finance, VP Marketing etc, or is this already > happening in the US. No. And not likely to happen in companies with ordinary products. As a general rule, "compliance" is seen as a necessary evil. It is a cost without an associated revenue (or customer-recognized need or benefit). Few companies want to give VP status (and an empire) to a non-revenue- generating function. Many companies measure the product incremental cost for "compliance." The objective is to find methods and means for minimizing these product costs. Furthermore, few companies recognize the work of "compliance" folks as prevention of future unanticipated costs such as failure of sales due to non-compliance, product liability, or even product recalls. The reason the work is not recognized is the difficulty of measuring the future cost of non-compliance, especially if the company has never had such an incident. > Second Question. Does the group think a formal qualification in > Compliance Management & CE Marking would be a good idea. While we may think this is a good idea, most professional managers in the field of compliance consider the job as one interim step in their career. If "compliance" is a non- revenue-generating activity, then the step to personal growth is to measure the cost of compliance for the duration of one's leadership, and add this to one's CV. Then, move on. Candidates for compliance management might find courses useful. However, the value of such qualifications is not for the long term. Another problem is that upper management doesn't want to be told that they are restricted by compliance rules insofar as setting objectives for the products and the company. They certainly don't want to feel that the only management folks qualified for managing a compliance function are those that are trained and qualified in compliance management. Formal qualification in compliance management may be seen by upper management as a power play where the compliance manager uses his knowledge to gain some degree of control over other managers. If "formal qualification" in compliance management is principally that of methodology for measuring and reducing cost of compliance, then I would think this would be a very good idea. Best regards, Rich --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail
Re: Quality Assurance and Product Approvals
Thanks Rich for your very detailed, interesting and thought provoking answer. I will need to reflect on your comments before responding. Regards Alan - Original Message - From: "Rich Nute" To: Cc: Sent: Monday, November 26, 2001 8:35 PM Subject: Re: Quality Assurance and Product Approvals > > > > Hi Alan: > > > > Two questions, does the group see a time when we have a VP Compliance on > > level terms with VP Finance, VP Marketing etc, or is this already > > happening in the US. > > No. And not likely to happen in companies with ordinary > products. > > As a general rule, "compliance" is seen as a necessary > evil. It is a cost without an associated revenue (or > customer-recognized need or benefit). Few companies > want to give VP status (and an empire) to a non-revenue- > generating function. > > Many companies measure the product incremental cost for > "compliance." The objective is to find methods and means > for minimizing these product costs. > > Furthermore, few companies recognize the work of "compliance" > folks as prevention of future unanticipated costs such as > failure of sales due to non-compliance, product liability, > or even product recalls. The reason the work is not > recognized is the difficulty of measuring the future cost of > non-compliance, especially if the company has never had such > an incident. > > > Second Question. Does the group think a formal qualification in > > Compliance Management & CE Marking would be a good idea. > > While we may think this is a good idea, most professional > managers in the field of compliance consider the job as one > interim step in their career. If "compliance" is a non- > revenue-generating activity, then the step to personal > growth is to measure the cost of compliance for the duration > of one's leadership, and add this to one's CV. Then, move > on. > > Candidates for compliance management might find courses > useful. However, the value of such qualifications is not > for the long term. > > Another problem is that upper management doesn't want to be > told that they are restricted by compliance rules insofar as > setting objectives for the products and the company. They > certainly don't want to feel that the only management folks > qualified for managing a compliance function are those that > are trained and qualified in compliance management. > > Formal qualification in compliance management may be seen by > upper management as a power play where the compliance > manager uses his knowledge to gain some degree of control > over other managers. > > If "formal qualification" in compliance management is > principally that of methodology for measuring and reducing > cost of compliance, then I would think this would be a > very good idea. > > > Best regards, > Rich --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and Product Approvals
Hi Alan: > Two questions, does the group see a time when we have a VP Compliance on > level terms with VP Finance, VP Marketing etc, or is this already > happening in the US. No. And not likely to happen in companies with ordinary products. As a general rule, "compliance" is seen as a necessary evil. It is a cost without an associated revenue (or customer-recognized need or benefit). Few companies want to give VP status (and an empire) to a non-revenue- generating function. Many companies measure the product incremental cost for "compliance." The objective is to find methods and means for minimizing these product costs. Furthermore, few companies recognize the work of "compliance" folks as prevention of future unanticipated costs such as failure of sales due to non-compliance, product liability, or even product recalls. The reason the work is not recognized is the difficulty of measuring the future cost of non-compliance, especially if the company has never had such an incident. > Second Question. Does the group think a formal qualification in > Compliance Management & CE Marking would be a good idea. While we may think this is a good idea, most professional managers in the field of compliance consider the job as one interim step in their career. If "compliance" is a non- revenue-generating activity, then the step to personal growth is to measure the cost of compliance for the duration of one's leadership, and add this to one's CV. Then, move on. Candidates for compliance management might find courses useful. However, the value of such qualifications is not for the long term. Another problem is that upper management doesn't want to be told that they are restricted by compliance rules insofar as setting objectives for the products and the company. They certainly don't want to feel that the only management folks qualified for managing a compliance function are those that are trained and qualified in compliance management. Formal qualification in compliance management may be seen by upper management as a power play where the compliance manager uses his knowledge to gain some degree of control over other managers. If "formal qualification" in compliance management is principally that of methodology for measuring and reducing cost of compliance, then I would think this would be a very good idea. Best regards, Rich --- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson:pstc_ad...@garretson.org Dave Healddavehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
Re: Quality Assurance and product approvals
Mike, Tania hits the nail on the head with her comments. Something that I find useful in this situation is a "Process Flowchart". These can be used for more than just chemical production. It more graphically illustrates the processes, interrelationships, and possible sequencing involved, especially when multiple people/departments are involved. These can be "nested" so that a high level flow chart can be shown to upper management (who only need the big picture) or initial trainees (who haven't a clue). More detailed ones can be used within departments or functions. Each one gives those within the process a bigger picture of what is suppose to be happening and gives them more information and motivation with which to make informed decisions. If one knows the impact of a decision outside their immediate realm of influence they may (and I emphasize may) make a decision that is positive for the entire process and not just their own little piece of it. It also makes it easier to spot failures/faults in the process. This leads to the ability of fixing the problem or revising the process. Where necessary, each of the blocks on the flow chart can have a more detailed flow chart showing the internal process (nesting). This could be continued until you actually reach a level where you are writing procedures; but, its main use is higher level viewing. A point of Tania's response to which I wish to emphasize is the need to involve others in the development. That cannot be stressed to much. It is amazing what comes out of the discussions as to how a process operates when those doing the work are asked how they think the process works. You will usually find a very diverse understanding of what people think is actually going on. Expect to be surprised yourself as to what actually is going on beyond your daily sight and the understanding others have of their roles. It is only at this point that you find out how different the "actual" process is to the "printed" one. It is at this time that you have to decide which is better, the "actual" process, the "printed" one, or another one altogether. You will probably find that both the "actual" and the "printed" processes have good elements and that somewhere in the middle is a more "optimum" process. There are some good software packages that are intended for process flow development. You can do the same with slide presentation graphic package but those intended for flow charting allow you to spend your time thinking instead of drawing. Well worth the minor cost. Oscar Overton oover...@lexmark.com (OAMO) Opinions are my own. "Tania Grant" on 11/21/2001 12:18:24 AM Please respond to "Tania Grant" To: "mike harris" , amund%westin-emission...@interlock.lexmark.com, "'EMC-PSTC Discussion Group'" cc:(bcc: Oscar Overton/Lex/Lexmark) Subject: Re: Quality Assurance and product approvals Hello Mike, It sounds as if your efforts were very well spent. I probably did not clarify that, in my opinion, people use the term "procedure" very loosely. Without having read your document (and therefore leaving myself open for criticism; but that's O.K.) I would say that what you wrote is not a procedure but more of a guideline or a higher level policy document. You are mostly explaining many things, providing information as to who is responsible to do what, but I don't believe you are really describing "how" those who are responsible are to perform their tasks. Thus, a procedure addresses repetitive tasks in detail, where the details are many and could probably be even very complex, and where probably the sequence of tasks is very crucial, and where you don't want people making mistakes no matter what their level of training is. Your document explains and describes "what" and describes "who" is to do what. If it is multi-departmental, it really falls into a category of a company wide policy. I can see that engineering, purchasing, regulatory, etc, would have their own procedures to support this higher level document. Now, why am I so fixated on not labeling such documents "procedures"? The problem with procedures is that there is usually a very defined format (usually Outline format) that lends itself beautifully to "order" and also to bureaucracy. There are times when you want bureaucracy and strict order, and there are times when you want to communicate, when you want people to understand and follow guidelines but you don't want to institute needless bureaucracy. How many of you have worked in a "procedurized" bureaucracy where there were many procedures that hardly anyone could follow or wanted to follow? The reason is because either the procedures were badly written and, most likely, were written
RE: Quality Assurance and product approvals
Tania has summed up the situation pretty well below, one that I can certainly relate to. What existed in my last company were: Procedures - to describe the high level policy; Work Instructions - for very specific, and sometimes critical (but not necessarily), usually repetitive tasks. Having separate WI's (1 or 2 pages at most) meant that they could be easily updated when required without loads of reviews by people at all levels of the organisation, because the Procedures were not being updated unless there was a significant policy change. But. While I agree that training people on the 'how' while also giving them the backgorund on the 'why' can achieve the goal (for the Regulatory function at least, which is what should really be talking about here), there must be documented in at least one place the procedure and work instructions i.e. the training manuals. Yes, by the letter of the gospel (ISO 9000:2000) there are only really 6 or 7 procedures that must be documented and 9000:2000 espouses the use of 'verbal procedures', but this will only work in very small companies which probably won't have a Regulatory Group anyway Trained people move on. The 'procedures' go with them. Brian -Original Message- From: owner-emc-p...@majordomo.ieee.org [mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Tania Grant Sent: 21 November 2001 05:18 To: mike harris; am...@westin-emission.no; 'EMC-PSTC Discussion Group' Subject: Re: Quality Assurance and product approvals Hello Mike, It sounds as if your efforts were very well spent. I probably did not clarify that, in my opinion, people use the term "procedure" very loosely. Without having read your document (and therefore leaving myself open for criticism; but that's O.K.) I would say that what you wrote is not a procedure but more of a guideline or a higher level policy document. You are mostly explaining many things, providing information as to who is responsible to do what, but I don't believe you are really describing "how" those who are responsible are to perform their tasks. Thus, a procedure addresses repetitive tasks in detail, where the details are many and could probably be even very complex, and where probably the sequence of tasks is very crucial, and where you don't want people making mistakes no matter what their level of training is. Your document explains and describes "what" and describes "who" is to do what. If it is multi-departmental, it really falls into a category of a company wide policy. I can see that engineering, purchasing, regulatory, etc, would have their own procedures to support this higher level document. Now, why am I so fixated on not labeling such documents "procedures"? The problem with procedures is that there is usually a very defined format (usually Outline format) that lends itself beautifully to "order" and also to bureaucracy. There are times when you want bureaucracy and strict order, and there are times when you want to communicate, when you want people to understand and follow guidelines but you don't want to institute needless bureaucracy. How many of you have worked in a "procedurized" bureaucracy where there were many procedures that hardly anyone could follow or wanted to follow? The reason is because either the procedures were badly written and, most likely, were written at the wrong level. Proper people with training have no trouble working without any procedures provided they know what is expected and who the other players are. You don't need a "procedure" to define this. But very often the purpose of actions, what is expected, and who the players are, are not explained, but the "how" is rendered in ludicrous detail. Thus, you end up with a "procedure" that is unworkable after 7 months. Procedures should be written either by the people who are performing the work, or at the next higher level; test engineering usually writes procedures for the test technicians to follow. However, I believe that it is better if the test technicians wrote their own test procedure and gave it to the test engineers for review. It is amazing how much knowledge can suddenly be gained during this exercise by both sides! I have written many multi-functional multi-departmental procedures, but I went to a great deal of time and effort to obtain input from those performing the various tasks. I was often surprised to receive different inputs from workers and their managers. Beware of highly placed managers writing detailed procedures telling others how to do their jobs, without honest input. Bureaucracy reigns! taniagr...@msn.com ----- Original Message ----- From: mike harris Sent: Tuesday, November 20, 2001 3:29 AM To: Tania Grant; am...@westin-emission.no; '
Re: Quality Assurance and product approvals
Hello Mike, It sounds as if your efforts were very well spent. I probably did not clarify that, in my opinion, people use the term "procedure" very loosely. Without having read your document (and therefore leaving myself open for criticism; but that's O.K.) I would say that what you wrote is not a procedure but more of a guideline or a higher level policy document. You are mostly explaining many things, providing information as to who is responsible to do what, but I don't believe you are really describing "how" those who are responsible are to perform their tasks. Thus, a procedure addresses repetitive tasks in detail, where the details are many and could probably be even very complex, and where probably the sequence of tasks is very crucial, and where you don't want people making mistakes no matter what their level of training is. Your document explains and describes "what" and describes "who" is to do what. If it is multi-departmental, it really falls into a category of a company wide policy. I can see that engineering, purchasing, regulatory, etc, would have their own procedures to support this higher level document. Now, why am I so fixated on not labeling such documents "procedures"? The problem with procedures is that there is usually a very defined format (usually Outline format) that lends itself beautifully to "order" and also to bureaucracy. There are times when you want bureaucracy and strict order, and there are times when you want to communicate, when you want people to understand and follow guidelines but you don't want to institute needless bureaucracy. How many of you have worked in a "procedurized" bureaucracy where there were many procedures that hardly anyone could follow or wanted to follow? The reason is because either the procedures were badly written and, most likely, were written at the wrong level. Proper people with training have no trouble working without any procedures provided they know what is expected and who the other players are. You don't need a "procedure" to define this. But very often the purpose of actions, what is expected, and who the players are, are not explained, but the "how" is rendered in ludicrous detail. Thus, you end up with a "procedure" that is unworkable after 7 months. Procedures should be written either by the people who are performing the work, or at the next higher level; test engineering usually writes procedures for the test technicians to follow. However, I believe that it is better if the test technicians wrote their own test procedure and gave it to the test engineers for review. It is amazing how much knowledge can suddenly be gained during this exercise by both sides! I have written many multi-functional multi-departmental procedures, but I went to a great deal of time and effort to obtain input from those performing the various tasks. I was often surprised to receive different inputs from workers and their managers. Beware of highly placed managers writing detailed procedures telling others how to do their jobs, without honest input. Bureaucracy reigns! taniagr...@msn.com - Original Message - From: mike harris Sent: Tuesday, November 20, 2001 3:29 AM To: Tania Grant; am...@westin-emission.no; 'EMC-PSTC Discussion Group' Subject: Re: Quality Assurance and product approvals Hi Tania, I just finished writing a procedure on agency certifications for a client (prompted by their ISO 9000 audit). It became partly glossary & partly encyclopedia so sales, marketing, etc could find definitions and explanations of what the agencies are and why we need the certifications. It identifies the different levels & types of certifications & why they are needed by various parties. It outlines who does what, as far as design (initial & ongoing), purchasing (ongoing - no stealth changes of critical parts), parts/materials inventory (traceability), etc. It defines who gets notified of new certifications & what records are kept & for how long. I agree with you completely that it would be never-ending to try to write a procedure to allow the untrained to do it all, so it does not explain how to conduct a project at any agency except in the most basic terms (tell the agency what you want to certify, get their cost estimate, write PO, provide samples & documentation, assist as needed). Much can be gained by having such a document, which will seem basic for any competent compliance engineer. It will so nice to refer people to the procedure for the routine questions, instead of doing Agency 101 for the umpteenth time. Mike Harris/Teccom -Original Message- From: Tania Grant To: am...@westin-emission.no ; 'EMC-PSTC Discussion Group' List-Post: emc-pstc@list
RE: Quality Assurance and product approvals
You are all making some excellent points. It would seem that many of us share commonality. Perhaps that is one of the underlying purposes of the quality organizations. When followed, the effects are positive and things move correctly, and in synch, but when exceptions are present... In my case, the compliance group and the engineering group are one. This obviously has good and bad implications. Brian makes an excellent point that has at times caused my hackles to raise more than once...the independence (or lack thereof) between the compliance department and the engineering department. In the company documents filed by two of these quality agencies, i.e. ISO 900x, A2LA, TUV or COMPASS, there is a clause that specifically mentions the requirement for this independence. Or, is it more of a 'suggestion'? There does not however, seem to be an audit check for departmental independence. I recently have become an ISO auditor, and I am uncertain there is, UNLESS I want to take it upon myself to press the issue. Since I work in the department, I cannot be assigned the task of auditing it, but I could express my concerns with the person assigned the audit of the EMC/Safety/Design engineering department. Hmm... I dont recall where these clauses are, but the purpose behind them is to express the importance of functional isolation between the interests of the two groups. In our case, this causes a disastrous effect on scheduling and allocation of resources because the conflicts are quick to rise and there is a weak attempt to resist. At times, we find ourselves pulled in two directions simultaneously. The 'Janus'..? All the planning, procedures and methods in the world cannot overcome this conflict if no one is willing to meet the challenge and push the issue. (as in our case) My poor boss has been subdued...and our compliance group is eternaly the whipping boy. I see the problem, but I am ineffective at fighting off the 800Lb gorilla's because they do not believe a lab rat...could read, think and speak. Ah, but I can AUDIT, or cause focus by another auditor...that would attract the attention of the QA folks (who seem to be beyond reproach). In the end, the quality of our output is in the hands of the lab rats who, take it upon themselves to ensure the letter of the standards are adhered to despite the conflict associated with the work. That makes it a thankless job, with little if any, appreciation. Ha!! what's that you say...you want a medal? -for driving up COSTS and delaying product release!!! If it were'nt for the beaurocracy...you would not have a job. [Ehler, Kyle] (my words) -Original Message- From: Brian McAuliffe [mailto:bally...@iolfree.ie] Sent: Tuesday, November 20, 2001 4:36 AM To: 'EMC-PSTC Discussion Group' Subject: RE: Quality Assurance and product approvals I think the point raised by Gary re: where the Compliance group fits into the organisation structure is more important than procedures/process, although I disagree with him about where that should be. Let me explain. Having a good working relationship with Engineering is indeed critical, however from my experience I believe it essential for the Compliance group to be organisationally independent of Engineering. If not, then there are always conflicts of interest when allocating the (usually limited) Compliance resources between: Engineering - there are 4 design reviews this week and preparation required for a safety pre-compliance test next week; Operations - the agency auditor is visiting next week and there is some prep needed; Sales/Marketing - the Russian approval is expiring in 2 weeks and you need to re-apply, prepare doc pack, etc. How do you prioritise without getting slack from at least one functional head ?? Obviously if the Compliance group is actually a group and not just 1 or 2 persons, then with a good understanding of the roles amongst the group members the above does not really pose a problem. However I do NOT believe this is the case, particularly in the current climate of lay-offs, with us Compliance folk are becoming less essential. Unless the role of the Compliance group is very narrow and involves only support of one function (which I doubt), I feel that an independent Compliance group is essential. It should be functionally independent to any other group and reporting to the MD, or, reporting to the QA Director/Manager. This will mean you can realistically argue for adequate resouces to do a professional job for all those groups requiring your services. You will have somebody independent at the right level in the organisation supporting the Compliance group - essential when $$$ are involved. Let's face it, no R&D Manager is going to approve headcount for a 2nd Compliance Engineer whose primary function is to do audits of the production facility to ensure critical components are controlled as they should, and, t
RE: Quality Assurance and product approvals
Morning Brian, et al. I don't have a large heartburn about the exact organizational chart location I have been in them all - well not actually sales I do have some standards* - and I find the debate very valuable! Location doesn't really create or fix all that many problems. You kind of trade one set of problems for the other. The absolute point of criticality is that the corporation has to have understand what it needs to get a product to market. That is established in the products requirement document, others may have different names. The things this group does, including Safety, EMC, and NEBS, among others are quite simply product requirements just like everything else in the document, in our case the ability to pass packets at line rate without packet loss, or maybe implementing spanning tree protocols etc. Take a look back at recent discussions about whether or not a DOC by itself was sufficient to accept product. The answer was generally no. That can affect a bottom line and that always gets attention from the highest levels. Why? Because some of the product features couldn't be independently verified and products aren't being purchased without it. We just stopped purchases of some very expensive pieces of equipment because of some operational bugs AND because of problems with their radiated emissions. That affected that companies bottom line for the quarter and that gets everybody's attention. Once the feature issue is understood then things start falling into place quite nicely. Making that understood is probably one of the more critical items we have to face, and it can be done from any organization. When the various prototype, pilot, or alpha builds are being planned they include the units I need for my job - that will range from three to six depending on the NEBS requirements, and these aren't inexpensive pieces of equipment. Schedules are a sneaking little tool. When being laid out its not a hard sale to point out that not having EUT's and having them on fixed dates starts putting day to day slips into the production release of the product. It also clearly identifies when more bodies are needed to implement the schedule. Something the big guys can evaluate very effectively. You're correct about the design review meetings and I spend a lot of time either in them or responding via e-mail or cell phone to them. Its not perfect but works very well. If I train the engineers well they become somewhat self monitoring and learn to get quick verifications when they have concerns. Spokane is an absolutely wonderful place to live but it means that for those tests I need to witness - EMC and NEBS etc, I spend a great deal of time in rectangular tubes at 30,000 feet trying to get to a rectangular box at the end of the day - traveling is so much fun - but a laptop, a very good electronic Engineering change process, a cell phone, and some first rate engineers and lab rats and it works very well - again independent of what organization I'm in. So get the features defined at step one, that will drive the allocations, tasks and schedules. The work with some great people who understand engineering and the full product development process - yes even sales has its good points, but empire builders are expressly excluded, and then work from anywhere. History has given me a strong preference for being inside the engineering department but your choice is just as. Gary *(It was a joke folks complain to me directly off line). -Original Message- From: Brian McAuliffe [mailto:bally...@iolfree.ie] Sent: Tuesday, November 20, 2001 2:36 AM To: 'EMC-PSTC Discussion Group' Subject: RE: Quality Assurance and product approvals I think the point raised by Gary re: where the Compliance group fits into the organisation structure is more important than procedures/process, although I disagree with him about where that should be. Let me explain. Having a good working relationship with Engineering is indeed critical, however from my experience I believe it essential for the Compliance group to be organisationally independent of Engineering. If not, then there are always conflicts of interest when allocating the (usually limited) Compliance resources between: Engineering - there are 4 design reviews this week and preparation required for a safety pre-compliance test next week; Operations - the agency auditor is visiting next week and there is some prep needed; Sales/Marketing - the Russian approval is expiring in 2 weeks and you need to re-apply, prepare doc pack, etc. How do you prioritise without getting slack from at least one functional head ?? Obviously if the Compliance group is actually a group and not just 1 or 2 persons, then with a good understanding of the roles amongst the group members the above does not really pose a problem. However I do NOT believe this is the case, particularly in t
RE: Quality Assurance and product approvals
I think the point raised by Gary re: where the Compliance group fits into the organisation structure is more important than procedures/process, although I disagree with him about where that should be. Let me explain. Having a good working relationship with Engineering is indeed critical, however from my experience I believe it essential for the Compliance group to be organisationally independent of Engineering. If not, then there are always conflicts of interest when allocating the (usually limited) Compliance resources between: Engineering - there are 4 design reviews this week and preparation required for a safety pre-compliance test next week; Operations - the agency auditor is visiting next week and there is some prep needed; Sales/Marketing - the Russian approval is expiring in 2 weeks and you need to re-apply, prepare doc pack, etc. How do you prioritise without getting slack from at least one functional head ?? Obviously if the Compliance group is actually a group and not just 1 or 2 persons, then with a good understanding of the roles amongst the group members the above does not really pose a problem. However I do NOT believe this is the case, particularly in the current climate of lay-offs, with us Compliance folk are becoming less essential. Unless the role of the Compliance group is very narrow and involves only support of one function (which I doubt), I feel that an independent Compliance group is essential. It should be functionally independent to any other group and reporting to the MD, or, reporting to the QA Director/Manager. This will mean you can realistically argue for adequate resouces to do a professional job for all those groups requiring your services. You will have somebody independent at the right level in the organisation supporting the Compliance group - essential when $$$ are involved. Let's face it, no R&D Manager is going to approve headcount for a 2nd Compliance Engineer whose primary function is to do audits of the production facility to ensure critical components are controlled as they should, and, to support Sales/Marketing to achieve product approvals worldwide. (To bring this back to procedures/process) There also needs to be a 'document' which highlights: 1. What services the Compliance group offer; 2. The inputs (from other groups) required, and the outputs to be expected from each service; 3. Turnaround time (this will never be 100% accurate) With a document such as this published it raises awareness among each of the functions that the Compliance group do have organisation-wide responsibilites and are not at the beck and call of just one group. It forces them to plan for compliance also. It gives the Compliance group more credibility and visibility, and maybe people will start to appreciate the . Brian -Original Message- From: owner-emc-p...@majordomo.ieee.org [mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Gary McInturff Sent: 19 November 2001 16:35 To: 'Tania Grant'; am...@westin-emission.no; 'EMC-PSTC Discussion Group' Subject: RE: Quality Assurance and product approvals Bottom line is that each program generates a set of milestones that identify a function, set of equipment required, and timeframe for getting them done, and there are a set of generic test suites, but generally the whole process is documented at very non-descript level. The rest of this is rational for the way it happens. Over the course of my career ( companies of 40 - to 1,000 employees) this function has 1) grown in scope, first just safety, then safety and EMC, then safety, EMC and DVT, currently its safety, EMC, DVT, and NEBS. 2) It has been shuffled from place to place. Engineering, QA, manufacturing, to marketing. I have always been able to direct it back to what I believe is the correct department - Engineering. Principally for, conservation of resources - I already have some lab rats ( I say this with humor they have saved me much time and grief over the years) , and equipment, I may have to expand the equipment set marginally but I don't have to duplicate it. Probably just as important, is that inside of engineering I have the most timely input into the design changes or recommendations up front. Being located with the design engineers gives us both immediate and personal contact. They can stop into my office, and do quite regularly, to ask questions or seek advice, and I can do the same. As for formality of process it has always been more a series of milestones rather than explicitly documented processes for the vary reason Tania states - things change and they can change rapidly. I do have a series of boilerplate tests such as temperature, etc but occasionally those tests end up confirming - not predicting - what the safety agencies find. I try to find the very earliest point at which I can submit product to the safety agencies and the product is not always 100% f
Re: Quality Assurance and product approvals
Hi Tania, I just finished writing a procedure on agency certifications for a client (prompted by their ISO 9000 audit). It became partly glossary & partly encyclopedia so sales, marketing, etc could find definitions and explanations of what the agencies are and why we need the certifications. It identifies the different levels & types of certifications & why they are needed by various parties. It outlines who does what, as far as design (initial & ongoing), purchasing (ongoing - no stealth changes of critical parts), parts/materials inventory (traceability), etc. It defines who gets notified of new certifications & what records are kept & for how long. I agree with you completely that it would be never-ending to try to write a procedure to allow the untrained to do it all, so it does not explain how to conduct a project at any agency except in the most basic terms (tell the agency what you want to certify, get their cost estimate, write PO, provide samples & documentation, assist as needed). Much can be gained by having such a document, which will seem basic for any competent compliance engineer. It will so nice to refer people to the procedure for the routine questions, instead of doing Agency 101 for the umpteenth time. Mike Harris/Teccom -Original Message- From: Tania Grant To: am...@westin-emission.no ; 'EMC-PSTC Discussion Group' Date: Monday, November 19, 2001 1:18 AM Subject: Re: Quality Assurance and product approvals Amund, Since I transferred, over more than 20 years ago, from Quality Assurance to Regulatory compliance/product safety, I will share with you my opinions and my experience. However, I would also be interested in hearing about the experience of others. In my opinion, QA and regulatory compliance are different enough functions that require different experiences and disciplines that would not necessarily make it effective for a QA organization to either write or enforce procedures on the regulatory compliance functions. That does not mean that regulatory compliance shouldn't have a more formal process and a procedure to go with it. For myself, I know that having a QA background made me a more effective regulatory "guru" at the company. But I don't see how the two can be meshed under the same umbrella without diluting one or the other. Both require focus but it would be a rare Janus that could manage this effectively. However, the regulatory processes could, and should, be integrated into the whole engineering design process;-- and so should the QA process. Thus, the two can and should help each other, but I just don't see that a QA oversight by itself would make the regulatory process better or more effective. Now, I have a problem with your statement "...have your companies made procedures which in details describes the product approval process from beginning to end ?" You are quite right that any procedure should describe a process in detail from beginning to end. This lends itself quite well to any and all test procedures, assembly of various parts, and other such functions where the same process is repeated over and over again. However, with the regulatory approval process, each product is different enough, that a procedure, especially one that is "detailed", would not work. And the approval process is not always "from the beginning to end" but very often just a test or two have to be repeated, but not all, and sometimes you just notify the authorities about this and that, and sometimes you don't, but only document it or write up a justification why a particular test is not required. So how do you write a procedure around this? If I had to religiously do all this, I would be writing a procedure practically every time I was submitting a new or providing changes to a product. And I sure as heck would have been very upset if someone else (say from QA) were writing these "procedures" for me, especially since they wouldn't know what was required, or how to achieve this. A procedure describes "how" something is done. If I don't know how to do it, I shouldn't be working in that position. If the QA person is writing such a procedure (and assuming they are effective at it, which is problematic) then they should be working in that position and not me. Thus, I am not in favor of "procedures". However, I am very much in favor of regulatory compliance plans that should be written for each new product, or a major regulatory up-date to a product. This compliance plan is really a communication device that informs Marketing, Engineering, QA, etc., the regulatory strategy: what the requirements are for this particular product, for which countries, to which standard
RE: Quality Assurance and product approvals
Bottom line is that each program generates a set of milestones that identify a function, set of equipment required, and timeframe for getting them done, and there are a set of generic test suites, but generally the whole process is documented at very non-descript level. The rest of this is rational for the way it happens. Over the course of my career ( companies of 40 - to 1,000 employees) this function has 1) grown in scope, first just safety, then safety and EMC, then safety, EMC and DVT, currently its safety, EMC, DVT, and NEBS. 2) It has been shuffled from place to place. Engineering, QA, manufacturing, to marketing. I have always been able to direct it back to what I believe is the correct department - Engineering. Principally for, conservation of resources - I already have some lab rats ( I say this with humor they have saved me much time and grief over the years) , and equipment, I may have to expand the equipment set marginally but I don't have to duplicate it. Probably just as important, is that inside of engineering I have the most timely input into the design changes or recommendations up front. Being located with the design engineers gives us both immediate and personal contact. They can stop into my office, and do quite regularly, to ask questions or seek advice, and I can do the same. As for formality of process it has always been more a series of milestones rather than explicitly documented processes for the vary reason Tania states - things change and they can change rapidly. I do have a series of boilerplate tests such as temperature, etc but occasionally those tests end up confirming - not predicting - what the safety agencies find. I try to find the very earliest point at which I can submit product to the safety agencies and the product is not always 100% functional from a design perspective, but 100% representative of the tests and construction that the safety agencies focusing on. Occasionally, that means a phone call or letter telling them that there are changes before they issue the certificates and possible some re-test but it helps move this part of the design process of the critical path. The same goes for EMC, although that can be a bit trickier and almost always means that I repeat many EMC tests, but the final ones are more validation than praying for a pass as the early units are, and we are pretty comfortable that the project will conclude on time rather than going back for adjustments - which might trigger conversations with more than one outside agency. Marketing puts out a products requirement document and engineering responds with and Engineering requirements. If they have missed agency marks etc, we will feed that back to them in this document. Once everyone agrees what has to be done, the design schedule is fleshed out, and there are a fixed set of prototypes, beta, and production units that are identified and build exclusively for my area or responsibilities, along with a pretty fixed amount of time to complete each of these tasks. - 6 to 8 weeks or whatever. Exactly, what is being done inside each of these tasks left undefined, just as the basic design function is undefined, once the system architecture is defined. I am responsible for project updates and status reports but they are also on a high, rather than detailed, level. Process, problems, design changes needed etc. Gary [Gary McInturff] -Original Message- From: Tania Grant [mailto:taniagr...@msn.com] Sent: Sunday, November 18, 2001 10:32 PM To: am...@westin-emission.no; 'EMC-PSTC Discussion Group' Subject: Re: Quality Assurance and product approvals Amund, Since I transferred, over more than 20 years ago, from Quality Assurance to Regulatory compliance/product safety, I will share with you my opinions and my experience. However, I would also be interested in hearing about the experience of others. In my opinion, QA and regulatory compliance are different enough functions that require different experiences and disciplines that would not necessarily make it effective for a QA organization to either write or enforce procedures on the regulatory compliance functions. That does not mean that regulatory compliance shouldn't have a more formal process and a procedure to go with it. For myself, I know that having a QA background made me a more effective regulatory "guru" at the company. But I don't see how the two can be meshed under the same umbrella without diluting one or the other. Both require focus but it would be a rare Janus that could manage this effectively. However, the regulatory processes could, and should, be integrated into the whole engineering design process;-- and so should the QA process. Thus, the two can and should help each other, but I just don't see that a QA oversight by itself would make the regulatory process better or more effective. Now, I have a problem with your
RE: Quality Assurance and product approvals
Here, here ! Best regards, Daniel E. Teninty, P.E. Managing Partner DTEC Associates LLC http://www.dtec-associates.com Streamlining the Compliance Process 5406 S. Glendora Drive Spokane, WA 99223 (509) 443-0215 (509) 443-0181 fax -Original Message- From: owner-emc-p...@majordomo.ieee.org [mailto:owner-emc-p...@majordomo.ieee.org]On Behalf Of Tania Grant Sent: Sunday, November 18, 2001 10:32 PM To: am...@westin-emission.no; 'EMC-PSTC Discussion Group' Subject: Re: Quality Assurance and product approvals Amund, Since I transferred, over more than 20 years ago, from Quality Assurance to Regulatory compliance/product safety, I will share with you my opinions and my experience. However, I would also be interested in hearing about the experience of others. In my opinion, QA and regulatory compliance are different enough functions that require different experiences and disciplines that would not necessarily make it effective for a QA organization to either write or enforce procedures on the regulatory compliance functions. That does not mean that regulatory compliance shouldn't have a more formal process and a procedure to go with it. For myself, I know that having a QA background made me a more effective regulatory "guru" at the company. But I don't see how the two can be meshed under the same umbrella without diluting one or the other. Both require focus but it would be a rare Janus that could manage this effectively. However, the regulatory processes could, and should, be integrated into the whole engineering design process;-- and so should the QA process. Thus, the two can and should help each other, but I just don't see that a QA oversight by itself would make the regulatory process better or more effective. Now, I have a problem with your statement "...have your companies made procedures which in details describes the product approval process from beginning to end ?" You are quite right that any procedure should describe a process in detail from beginning to end. This lends itself quite well to any and all test procedures, assembly of various parts, and other such functions where the same process is repeated over and over again. However, with the regulatory approval process, each product is different enough, that a procedure, especially one that is "detailed", would not work. And the approval process is not always "from the beginning to end" but very often just a test or two have to be repeated, but not all, and sometimes you just notify the authorities about this and that, and sometimes you don't, but only document it or write up a justification why a particular test is not required. So how do you write a procedure around this? If I had to religiously do all this, I would be writing a procedure practically every time I was submitting a new or providing changes to a product. And I sure as heck would have been very upset if someone else (say from QA) were writing these "procedures" for me, especially since they wouldn't know what was required, or how to achieve this. A procedure describes "how" something is done. If I don't know how to do it, I shouldn't be working in that position. If the QA person is writing such a procedure (and assuming they are effective at it, which is problematic) then they should be working in that position and not me. Thus, I am not in favor of "procedures". However, I am very much in favor of regulatory compliance plans that should be written for each new product, or a major regulatory up-date to a product. This compliance plan is really a communication device that informs Marketing, Engineering, QA, etc., the regulatory strategy: what the requirements are for this particular product, for which countries, to which standards, where the various tests will be performed, the approximate time assuming only one sample is available, and so forth. I am in favor, when a later update is made to the same product, to add an addendum to the same plan rather than generate a brand new plan. This way you can only add the delta tests that have to be done rather than start from scratch. And you have a history of the compliant process in one convenient location. Note that a compliance plan describes "what" is to be done and sometimes "why", if that is crucial, but it does not really go into the details of the "how". I don't want to start writing "how" I thermocouple the various components to get the product ready for safety heating tests! That, I consider, is part of training;-- and I have trained many to do this, all without benefit of writing any "procedures." However, I do insist (and I believe that all companies also do this) that there is a Hi-pot test procedure available (and I usually review it), and that designated personnel are proper
Re: Quality Assurance and product approvals
Amund, Since I transferred, over more than 20 years ago, from Quality Assurance to Regulatory compliance/product safety, I will share with you my opinions and my experience. However, I would also be interested in hearing about the experience of others. In my opinion, QA and regulatory compliance are different enough functions that require different experiences and disciplines that would not necessarily make it effective for a QA organization to either write or enforce procedures on the regulatory compliance functions. That does not mean that regulatory compliance shouldn't have a more formal process and a procedure to go with it. For myself, I know that having a QA background made me a more effective regulatory "guru" at the company. But I don't see how the two can be meshed under the same umbrella without diluting one or the other. Both require focus but it would be a rare Janus that could manage this effectively. However, the regulatory processes could, and should, be integrated into the whole engineering design process;-- and so should the QA process. Thus, the two can and should help each other, but I just don't see that a QA oversight by itself would make the regulatory process better or more effective. Now, I have a problem with your statement "...have your companies made procedures which in details describes the product approval process from beginning to end ?" You are quite right that any procedure should describe a process in detail from beginning to end. This lends itself quite well to any and all test procedures, assembly of various parts, and other such functions where the same process is repeated over and over again. However, with the regulatory approval process, each product is different enough, that a procedure, especially one that is "detailed", would not work. And the approval process is not always "from the beginning to end" but very often just a test or two have to be repeated, but not all, and sometimes you just notify the authorities about this and that, and sometimes you don't, but only document it or write up a justification why a particular test is not required. So how do you write a procedure around this? If I had to religiously do all this, I would be writing a procedure practically every time I was submitting a new or providing changes to a product. And I sure as heck would have been very upset if someone else (say from QA) were writing these "procedures" for me, especially since they wouldn't know what was required, or how to achieve this. A procedure describes "how" something is done. If I don't know how to do it, I shouldn't be working in that position. If the QA person is writing such a procedure (and assuming they are effective at it, which is problematic) then they should be working in that position and not me. Thus, I am not in favor of "procedures". However, I am very much in favor of regulatory compliance plans that should be written for each new product, or a major regulatory up-date to a product. This compliance plan is really a communication device that informs Marketing, Engineering, QA, etc., the regulatory strategy: what the requirements are for this particular product, for which countries, to which standards, where the various tests will be performed, the approximate time assuming only one sample is available, and so forth. I am in favor, when a later update is made to the same product, to add an addendum to the same plan rather than generate a brand new plan. This way you can only add the delta tests that have to be done rather than start from scratch. And you have a history of the compliant process in one convenient location. Note that a compliance plan describes "what" is to be done and sometimes "why", if that is crucial, but it does not really go into the details of the "how". I don't want to start writing "how" I thermocouple the various components to get the product ready for safety heating tests! That, I consider, is part of training;-- and I have trained many to do this, all without benefit of writing any "procedures." However, I do insist (and I believe that all companies also do this) that there is a Hi-pot test procedure available (and I usually review it), and that designated personnel are properly trained on how to run these tests, whether this function is under the QA or manufacturing test umbrella. Thus, I consider that the regulatory functions (safety, EMC, telco, Bellcore, etc.) should be part of the overall design process, to the release to manufacturing production, and finally, to the eventual "death" of the product. Note that this product life cycle procedure is for the overall product process, and not just for the regulatory approval process alone.It is desirable that the design process be documented, probably under a series of procedures, and, therefore, the regulatory requirements be inserted in the appro