From brada@kiv.zcu.cz Fri Apr 24 08:52:42 1998 Date: Fri, 17 Oct 1997 09:55:18 +0200 From: Premek Brada To: brada@kiv.zcu.cz Subject: [Fwd: Re: ISO 9000 origins?] [ Part 1: "Included Message" ] Date: 13 Oct 1997 18:16:10 GMT From: Justus Pendleton Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? [btw...I hope nothing below sounds overly harsh...it certainly isn't directed at Jerry Heyman or anything similar. I'm just trying to understand the rationale for having ISO 9000 certification.] In article <61tg3b$d3h24@aux.stedwards.edu>, Jerry Heyman wrote: >My understanding of ISO9000 is that it was initially a US >DoD initative, though obviously not called ISO9000. It was >then adopted as a manufacturing standard by ISO - and then >applied to software. So already we are operating under the assumption that what helps us attain quality in one industry will help us attain quality in another---vastly different---industry. Interesting foundation. >ISO9000 certification unto itself will not guarantee that >you produce a better product. It is totally possible that >Ford Motor could have been ISO9000 (if it existed at the >time) and still produced the Pinto. A 1996 ISO 9000 Survey with 1880 repondents asked "Most Important Reasons For Attaining ISO 9000 Registration": 1. Quality Benefits 28.6% 2. Customer Demand/Expectation 27.6% 3. Market Advantage 14.4% 4. Corporate Mandate 11.5% 5. Requirements of EU regs. 7.8% 6. Part of larger strategy 6.6% 7. Other & no answer 3.5% I'm guessing that most of the customer demand for ISO 9000 certification is due to a perception of quality benefits as well. Which gives us over 60% of those who have ISO 9000 certification do it because they believe it will reward them with quality benefits. Which, at least in the case of software, has simply not been demonstrated. I also read that "one of the basic facts about ISO 9000 is that it doesn't certify the quality of a product or service. It's purpose is to provide a quality system...that will provide a consistent method doing things (sic) in a business...ISO 9000 should be viewed as a basic foundation for a management system for the quality of product and services. It needs to be supplemented..." So I guess I have two questions: - It sounds like by itself ISO 9000 is pretty much nothing. It has no intrinsic value or worth (except as a hoop that multinational companies have to jump through). It does not increase quality or productivity. All such productivity and quality gains much be made through other efforts in conjunction with ISO 9000...and it is unclear whether those efforts are hindered or helped by the imposition of ISO on them. On the flip side you have to spend money (I have no idea how much, but it's probably a decent chunk of change) to get certified and to maintain that certification. So far I see no benefits and lots of cost. So why do companies do it? Is it just a fad among managers and customers? - What exactly is the empirical and/or theoretical backing for the assumption that an approach such as ISO 9000 can be uniformly applied to such a wide range of industries? If, indeed, it was originated in the manufacturing world, what is the rationale for expecting it to have effects outside of that particular field of endeavour? It seems that differences between manufacturing and, for instance, research and development, are numerous enough to invalidate the presumption that you can apply ISO 9000. >What ISO9000 states is that you have a documented process, that >everyone involved knows the process, where the relevant documentation >is located, and that it is followed. It makes NO judgement >as to whether the process is good/bad - just that you have one >and its documented. And the idea is that you can't improve on anything you can't repeat? And you can only repeat that which has been thoroughly documented? (Sorry if that comes across as belligerent...that isn't my intent.) -- Justus Pendleton justus.j.pendleton@lmco.com Truth is the highest thing that man may keep. Chaucer. The Frankeleines Tale. Line 11789. [ Part 2: "Included Message" ] Date: Wed, 15 Oct 1997 18:45:35 -0400 From: "Scott P. Duncan" Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? > Maybe the only reason that > the Department of Defense started the CMM and ISO > initiatives is because they continually bought poor quality > products? The rules of the acquisiton process which the government follows do make it harder to negotiate higher product quality. When it came to software, inexperience of the acquirers had a lot to do with the desire to have some form of external standard for try- ing to ensure higher quality in delivered systems. On the other hand, I would not use the word "continually" as much as emphasize that inefficiencies in the process and the contract structure lead to problems for buyer and seller. For example, no incentive to reuse software or make it reusable means redeveloping things and paying for them over and over. Or contracting where one party gets to do systems engineering, another does the design and implementation, and another gets maintenance can result in less than optimal costs and system evolution. Hence, the low-bid approach used for many years was not working to the government's satisfaction. Some form of technical analysis of a supplier's capbility and likelihood for improvement was sought. ISO 9000 and CMM are the result of trying to codify ideas about good practices in quality system management and software engineer- ing. Excessive emphasis on documentation over the reasonableness of what is being documented is a flaw in the commercialization of the audit business which is not regulated by ISO or SEI. ISO does not certify companies or auditors; SEI certifies the education and training of lead assessors but not the assessments, per se. Neither body has the funds to do this nor does it seem to be desired by the members and/or funding bodies. [My information behind saying all this comes directly from talks given by the SEI process program staff, government bodies, suppliers to the government, and experience on ISO standards groups.] [ Part 3: "Included Message" ] Date: Fri, 17 Oct 1997 09:15:43 +1000 From: Chris Kuan Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? Frank A. Adrian wrote: > > Chris Kuan wrote in message <34456198.6CBE@sig.please>... > >Justus Pendleton wrote: > >> Maybe the only reason that > >> the Department of Defense started the CMM and ISO > >> initiatives is because they continually bought poor quality > >> products? Maybe attempts like the CMM and ISO are covering > >> up symptoms rather than addressing the underlying problem > >> (don't ask me exactly what that might be). > It seems more to the point that DoD should have looked at their own internal > procurement, contracting, and acceptance processes before trying to improve > their suppliers'. I know that the DoD does try to continually improve - it > just doesn't seem to work very well or very quickly, especially in this > area. I think I'd look at even Microsoft as a prototype on how to improve > quality before I'd look to the DoD's relation with its contractors as the > stellar example. The quality of Micorsoft's products has gone up > significantly in the past 6 or 7 years, while maintaining organizational and > profitability growth, while the DoD's procurement policies remain a quagmire > of unneeded, mis-specified systems with resultant cost overruns. Any suggested reasons? - Chris Kuan, BHP Information Technology Concatenate for email: kuan.chris.ch @ bhp.com.au Phone : +61 2 4275 5555 Fax : +61 2 4275 5547 "A Design Pattern is something that got left out of the language" - Richard O'Keefe [ Part 4: "Included Message" ] Date: 15 Oct 1997 15:52:40 -0400 From: Mike Charlton Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? jpendlet@can402.sanders.lockheed.com (Justus Pendleton) writes: > [Let me again preface this by saying that in no way should > this be construed as a personal attack again Mike Charlton > (or anyone else who disagrees with my personal viewpoint).] I certainly won't take it as such. In fact, I don't think I really disagree with your viewpoint :-). ISO9000 has good points and bad points. As an ISO line agent in Nortel, it is my job to ensure that the people in my group are ISO compliant. I don't personally feel that ISO9000 registration is necessary _or_ sufficient for continuous improvement. My experience has been that it can help. (It can also be an impediment if used incorrectly, as another poster pointed out). > > In article <1jwoh4smkah.fsf@bmerh789.ca.nortel.com>, Mike Charlton wrote: > >The biggest enemy in an ad-hoc development environment is opinion. > >If you work in a big enough company, there are lots of widely disparate > >and conflicting opinions and assumptions. To improve effectively, you > >have to provide an objective method for evaluating your performance and > >the reasons for that performance. > > I don't see ISO9000 as eliminating opinion in any way what > so ever. All that I do see is that the winning opinion gets > written down and conflicting opinions (a.k.a. improvement, > "differences", "the wrong way", and various others) are more easily > squelched (since they aren't "part of the process"). Hmm... What can I say? Yes. At that point you can (and should, but don't have to) evaluate the opinion against objective measurements. Then improve. Everyone has to start somewhere. If you have a cool new idea how to do something, write it down, get some buy-in from management and start a pilot project. Compare it to the baseline processes. ISO9000 does not insist that there is one process for everything. You just have to document what you want to do *before you do it*. You also have to keep records to show that you did what you said you would do. [ Some stuff deleted ] > I realize that > I'm glossing over a lot of middle ground between those two > extremes -- but I'm unconvinced that the continuing costs of > rigid ISO9000 compliance are in anyway offset by the > unquantifiable gains it gives you. What are the costs? Are the gains really unquantifiable? These are rhetorical questions. I'll answer them based on my opinion. There are 70,000 people working at my company. Of course not all of them are programmers :-), but only a small percentage of these people are skilled enough to be let loose on a 30 million line project and not screw it up badly. (I hope Nortel doesn't mind me saying some of this...) I have seen code checked in to our configuration management system that doesn't compile (syntax errors). I have seen legacy code that was delivered to customers that never worked in the first place (it was not tested at all). None of this happens any more ;-). In any company that has anything more than a small number of highly skilled professionals, there is a need for process that reminds people what they are supposed to do (IMHO). In order to be sure that people actually read these processes, you need to collect records showing that activities were completed. Given this, the cost of ISO9000 registration is negligable. What are the benefits? You get to hang a cool sign at the front of building. Seriously. It is a marketing requirement and nothing more. My company could not sell anything if we were not ISO9000 compliant. End of story. > "Currently, we teach and insist that standards be written and > followed. However, we fail to teach that the point is to be > able to measure statistically stable system performance and > that successful systematic continuous improvement can only > start once we have the stable system. " -- Tom Gilb. No argument here. I left it in because I thought it was a good point :-). [ Some more stuff deleted ] > >I believe ISO9000 *can* help, but it doesn't have to. > >ISO9000 is about consistent results. "Consistenlty bad" is > >perfectly acceptable. > > The whole point of ISO9000 is that it provides (or says it > does) a foundation upon which continuous process improvement > can take place. However, based on my limited knowledge of > ISO9000 I don't see that if enforces continuous improvement > in any way. In that regard I see ISO9000 as a straw man -- > and a very expensive one at that. Apart from the last sentence, I would have to say "yes" again. Reread your own writing. "provides ... a foundation [for] continuous improvement." -- "I don't see that it enforces continous improvement". Yes. You can use the foundation or not. As I alluded to earlier, ISO9000 is one way to go to start process improvement initiatives. It is not the only (or even necessarily the best) way to go. It *does* let you hang up that nifty sign, though. > Would companies be better served expending their limited > resources towards achieving "good" processes that may or may > not be consistent? Or towards "consistent" processes that > may or may not be good. Inconsistent, but good processes are vulnerable to well meaning, but incompetant people. As we all know, pressure in this industry is enourmous. How many times have we heard, "Can we save time by skipping this 'analysis' phase"? How many times have we given in to the pressure, with disasterous consequences? > P.S. If you made it to the end of my entire long winded > post give yourself two Scoobie Snacks. ditto Mike [ Part 5: "Included Message" ] Date: Wed, 15 Oct 97 09:47:21 GMT From: Martin Tom Brown Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? In article <1jwoh4smkah.fsf@bmerh789.ca.nortel.com> mikechar@nortel.ca "Mike Charlton" writes: > jpendlet@can402.sanders.lockheed.com (Justus Pendleton) writes: > > [ Sorry, lost the attribution for the other quote ] > > > >What ISO9000 states is that you have a documented process, that > > >everyone involved knows the process, where the relevant documentation > > >is located, and that it is followed. It makes NO judgement > > >as to whether the process is good/bad - just that you have one > > >and its documented. Crucially I have known environments where the maintainence of the cubic yards of procedures became an end in itself. And worse it became very hard to justify changes to processes because of extra work involved in updating the controlled documents & procedures. > > And the idea is that you can't improve on anything you can't > > repeat? And you can only repeat that which has been > > thoroughly documented? (Sorry if that comes across as > > belligerent...that isn't my intent.) Part of it comes down to job knowledge and worker skills. If you have a high staff turnover (as most Western companies do) then it clearly pays to have everything possible documented. If people stay with the same company for life it is less compelling. > I would have to say a reserved "yes" to those questions. While it is > ture that you *can* improve on something you can't repeat, it is hard to > do it in a controlled fashion. If you don't know what you did, how > do you know what improved it? How can you improve on the improvement > without understanding what was good about the improvement? Natural selection (see Dawkins, The Blind Watchmaker) and evolution manage quite well without a huge rule book of ISO9000 procedures. For many routine tasks clear concise written procedures are an excellent idea. I have not always seen that output from ISO9000 :( > I believe ISO9000 *can* help, but it doesn't have to. ISO9000 is about > consistent results. "Consistenlty bad" is perfectly acceptable. I believe the intentions of ISO9000 were good, but the implementation in many places leaves a lot to be desired. If a reproducible product is all that you want then fine, but it can also lock in mediocracy. Regards, -- Martin Brown __ CIS: 71651,470 Scientific Software Consultancy /^,,)__/ [ Part 6: "Included Message" ] Date: Tue, 14 Oct 1997 09:02:57 -0400 From: Allan Davidson Newsgroups: comp.software-eng Subject: Re: ISO 9000 origins? I think the origin of ISO 9000 is something like this:- In the begining, there were several quality standards which customers (motor manufacturers, defence, etc) demanded their suppliers adhered to, and audited them to make sure. Each customer had their own standards which meant that some suppliers who had several customers were being audited very frequently and against differing standards each time. Someone (and this was when software was in its infancy) had the idea that if there was one universal standard, life would be simpler for everyone. Out of this came British Standard 5760 which then became ISO9000. To some extent BS5760/ISO9000 became the lowest common denominator of many standards so it was/is less specific than some of the customer standards. After ISO9000 was first published some people started to ask if it applied to the production of software, and ISO9000-3 was developed. The point is that the origins of ISO9000 are that it was customers who were demanding evidence of the way a company operated, rather than relying on testing the goods. -- Usual Disclaimers Apply Allan Davidson Manager, Process & Quality NCR Financial Systems Dundee, Scotland Jerry Heyman wrote in article <61tg3b$d3h24@aux.stedwards.edu>... > Justus Pendleton (jpendlet@can402.sanders.lockheed.com) wrote: > : I'm curious if anyone knows the theoretical and/or empirical > : underpinnings of ISO 9000. I assume (maybe wrongly) that > : someone didn't just say, "You know what? I bet if they > : document everything they'll provide better products." I'm > : curious about finding out exactly what experimental and/or > : real-world evidence supported advocating the implementation > : of ISO 9000 (i.e. evidence that existed _before_ it was > : first advocated). > > My understanding of ISO9000 is that it was initially a US > DoD initative, though obviously not called ISO9000. It was > then adopted as a manufacturing standard by ISO - and then > applied to software. Remainder Snipped