OT? ISO9000 -- The Big Picture

Vladimir Vassilevsky wrote:
>
>
> Jerry Avins wrote:
>
>> Rune Allnor wrote:
>>
>>> On 3 Sep, 21:14, Randy Yates <ya...@ieee.org> wrote:
>>
>>
>> ...
>>
>>>> I would think that establishing a level of competency and trust with
>>>> a company/contractor is the best you can do.
>>>
>>>
>>> It isn't. Writing a good contract is a lot better.
>>
>>
>> Let me add that a /really/ good contract says not merely "X will do
>> such and such," but makes it explicit what will happen if he doesn't.
>
> This is a really bad contract; it indicates the complete mistrust and
> the lack of the common sense between the parties. It also indicates that
> nobody is interested in getting to the actual business.
>
> My experience tells me the more the parties are interested in getting
> the job done, the less of bullshit and bureaucracy are involved.

Funny you should say that. Things frequently go awry in the construction
of large buildings and installations. Usually, the issues can be
resolved satisfactorily, but sometimes they end up in arbitration or a
court of law. I found that rather than writing unspecified damages into
a contract that an arbitrator or court would have to make explicit, most
of my contractors were pleased to have the matters spelled out in
advance. One negotiator told me that he liked my (at that time) novel
way to write a contract because -- his words -- it is better to play
chess than poker.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

On 4 Sep, 22:15, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
> On Tue, 04 Sep 2007 14:43:33 -0500, Vladimir Vassilevsky
>
>
>
>
>
> <antispam_bo...@hotmail.com> wrote:
>
> >Jerry Avins wrote:
>
> >> Rune Allnor wrote:
>
> >>> On 3 Sep, 21:14, Randy Yates <ya...@ieee.org> wrote:
>
> >> ...
>
> >>>> I would think that establishing a level of competency and trust with
> >>>> a company/contractor is the best you can do.
>
> >>> It isn't. Writing a good contract is a lot better.
>
> >> Let me add that a /really/ good contract says not merely "X will do such
> >> and such," but makes it explicit what will happen if he doesn't.
>
> >This is a really bad contract; it indicates the complete mistrust and
> >the lack of the common sense between the parties. It also indicates that
> >nobody is interested in getting to the actual business.
>
> >My experience tells me the more the parties are interested in getting
> >the job done, the less of bullshit and bureaucracy are involved.
>
> "Trust" does have a place in contract agreements, but it's a good way
> to get screwed, too. If parties _really_ do trust each other, then
> they won't object to protective clauses in the contract.
>
> To me the purpose of a contract is to reduce the amount of BS and
> bureaucracy in the long term. i.e., you agree up front how things
> should be handled with the idea that once the agreement is made work
> can proceed smoothly.

This is exactly how I view a contract, and the purpose of the
ISO9000 procedures as well. The "contract" is an agreement
between two different companies or organizations; the ISO9000
covers the same purpose internal to one company or organization.

Rune

On 5 Sep, 05:55, Jerry Avins <j...@ieee.org> wrote:

> One negotiator told me that he liked my (at that time) novel
> way to write a contract because -- his words -- it is better to play
> chess than poker.

Well, yes. Chess is a very fascinating game. No luck or chance
is involed, the rules are simple enough for a 10-year-old to learn,
and one can not hide anything from the opponent. Nor can he
hide anything from you.

Rune

DSP-Newbie wrote:
> pal.debabrata123 wrote:
>
>> Great, but "improving the measurement" is nothing but the process of
>> testing, but how do I improve the things which are being tested, the
>> devices under test( DUT) ?
>
> Implementing ISO9000 does not necessarily guarantees you will be making
> a better product after certification. A ISO9000 certification only
> states that Company A is making product B according to specification C
> in a carefully controlled, calibrated, administered production environment.

Actually, ISO9000 guarantees you won't be making a better product. Or a
worse one. ISO9000 is only about turning them out consistently of the
current quality.

If your product improves its through a separate activity, you need to
adjust your ISO9000 documentation to correlate with those improvements.
If the product improves, and you didn't adjust your ISO9000
documentation, your certifying agency might want to have a chat with you.

> Carefully measuring critical production parameters _may_ result in a
> better product, closer tolerances, faster delivery, or whatever product
> property is considered to be important for the client.

Closer tolerances is not the domain of ISO9000. Consistent tolerances is.

Faster delivery is not the domain of ISO9000. Understanding what
delivery you can achieve, and being consistent about it, is.

Improving whatever product property the client considers important is
not the domain of ISO9000. Only consistency of that property is.

> To answer the question: measurement can be improved by more accurate
> calibration procedures, improving measuring techniques, hiring
> specialised personnel, etc...

Regards,
Steve

Jerry Avins wrote:
> Rune Allnor wrote:
>> On 3 Sep, 21:14, Randy Yates <ya...@ieee.org> wrote:
>
> ...
>
>>> I would think that establishing a level of competency and trust with
>>> a company/contractor is the best you can do.
>>
>> It isn't. Writing a good contract is a lot better.
>
> Let me add that a /really/ good contract says not merely "X will do such
> and such," but makes it explicit what will happen if he doesn't.

I thought what happens is pretty much implicit in the US - sleazy
lawyers at 10 paces. :-)

"Jerry Avins" <jya@ieee.org> wrote in message
news:nsWdnXfsX9E8tUPbnZ2dnUVZ_rWtnZ2d@rcn.net...

> >> Let me add that a /really/ good contract says not merely "X will do
> >> such and such," but makes it explicit what will happen if he doesn't.
> >
> > This is a really bad contract; it indicates the complete mistrust and
> > the lack of the common sense between the parties. It also indicates that
> > nobody is interested in getting to the actual business.
> >
> > My experience tells me the more the parties are interested in getting
> > the job done, the less of bullshit and bureaucracy are involved.
>
> Funny you should say that. Things frequently go awry in the construction
> of large buildings and installations. Usually, the issues can be
> resolved satisfactorily, but sometimes they end up in arbitration or a
> court of law.

If someone desires to screw up everything and/or to take someone else to the
court, he can do that regardless of the contract. The examples are numerous.
The contract is only one of the arguments; its importance should not be
underestimated and overestimated.

> I found that rather than writing unspecified damages into
> a contract that an arbitrator or court would have to make explicit, most
> of my contractors were pleased to have the matters spelled out in
> advance. One negotiator told me that he liked my (at that time) novel
> way to write a contract because -- his words -- it is better to play
> chess than poker.

A chess play with a fool stuffed with the sense of self importance or a
paranoid holding a gun behind his back is not going to be worth the candles.
Even if it works out as a one time deal, there is unlikely to be any
prospective with this kind of attitude.

VLV

"Steve Underwood" <steveu@dis.org> wrote in message
news:fblp4h$e7$1@home.itg.ti.com...
> Actually, ISO9000 guarantees you won't be making a better product. Or a
> worse one. ISO9000 is only about turning them out consistently of the
> current quality.
>
> If your product improves its through a separate activity, you need to
> adjust your ISO9000 documentation to correlate with those improvements.
> If the product improves, and you didn't adjust your ISO9000
> documentation, your certifying agency might want to have a chat with you.

Consequently, the incentive of a product improvement is chilled down by tons
of ISO paperwork.

VLV

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:1188972635.946087.265490@w3g2000hsg.googlegro ups.com...
> On 5 Sep, 05:55, Jerry Avins <j...@ieee.org> wrote:
>
> > One negotiator told me that he liked my (at that time) novel
> > way to write a contract because -- his words -- it is better to play
> > chess than poker.
>
> Well, yes. Chess is a very fascinating game. No luck or chance
> is involed, the rules are simple enough for a 10-year-old to learn,
> and one can not hide anything from the opponent. Nor can he
> hide anything from you.

You haven't yet engaged in a business, but you are already thinking how to
overplay your partner.
Wonderful start, isn't it?

VLV

Steve Underwood <steveu@dis.org> writes:

> Closer tolerances is not the domain of ISO9000. Consistent tolerances is.

Not necessarily true.

> Faster delivery is not the domain of ISO9000. Understanding what
> delivery you can achieve, and being consistent about it, is.

Not necessarily true.

> Improving whatever product property the client considers important is
> not the domain of ISO9000. Only consistency of that property is.

Not necessarily true.

ISO9001 specifically addresses improvement. If tolerances are written
up in the quality manual as a process measure, and there is a business
failure due to the poor tolerance, then improvement is called for.

Same with faster delivery; same with whatever product property.

I've used "necessarily" because it all depends on what metrics you're
using... which is entirely up to the writer(s) of the quality manual.

If any of these properties is acceptable, then there's no real
business motivation to improve... and there's no real mechanism in ISO
to improve.

Just a nit-pick ;-)

Ciao,

Peter K.

--
"And he sees the vision splendid
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Vladimir Vassilevsky wrote:
> "Steve Underwood" <steveu@dis.org> wrote in message
> news:fblp4h$e7$1@home.itg.ti.com...
>> Actually, ISO9000 guarantees you won't be making a better product. Or a
>> worse one. ISO9000 is only about turning them out consistently of the
>> current quality.
>>
>> If your product improves its through a separate activity, you need to
>> adjust your ISO9000 documentation to correlate with those improvements.
>> If the product improves, and you didn't adjust your ISO9000
>> documentation, your certifying agency might want to have a chat with you.
>
> Consequently, the incentive of a product improvement is chilled down by tons
> of ISO paperwork.

I've encountered numerous bugs, inefficiency, possible cost reductions,
etc. that would have been really really easy to implement, but the
paperwork involved made people just look the other way. You need to take
great care over the possible knock-on consequences any little change
might unexpectedly produce, but any improvement process based on lots of
paperwork is doomed from the outset.

Steve