Reading
|
PanelSoft User Interfaces and Usability for Embedded Systems |
Feedback to "ISO 9000 Backlash"- Murphy's Law, January 2002Read the original artilce at ISO 9000 Backlash Dear Niall, I believe, almost on a level of conspiracy, that the entire ISO9000 standards approach has been an attack (mainly from the EC front) on the Western world's corporations to force everyone to function as inefficient as those that orchestrated it. Here we are in a world that is talking "paperless" and the standards organization is creating the biggest peppermill of history! I have resisted to comply nor move my organization towards any ISO9000 standardization process. We implement what is good but we do not implement anything that reduces our ability to be productive. Much of the ISO9000 spirit is derived from the "quality" movement of the last 20 years. Much of this was fueled by large corporations demanding programs to develop quality to the levels of Japan without any consideration that the culture of Japan is what makes their quality standard and not the methods we in the west have interpreted from Japanese behavior. Quality works in Japan because of "protecting" one's face and this almost genetic behavior is the key to everything in the East and how it works. Japan being the finest refinement. Now that our "quality mavens" have added costs to our products without direct improvements they have turned to ISO9000 standards in their zeal for beaucratic fulfillment. A few examples... I purchase sensors from a small company. Their largest customer forced them to become ISO certified. Soon there after I was told that they could not afford to sell me sensors in small quantities because the paperwork cost them so much to process that they lost money until the quantity hit certain levels. I still purchase from them but now I receive reams of paper with each unit, often there are defects and there are frequent lack of quality service issues that never occurred before. Why? Because individuals take less responsibility and rely on the paper to do the job instead of themselves. Work process flow has process flaws with no one looking to find them. My own partner's now find that they can no longer issue small PO amounts for items because the process cost too much. Now they have frequent losses in production because the small part they needed was not purchased for service inventory because of the trouble it is to issue a PO. The list goes on... What is interesting to note is that these standards had their birth in countries which WERE the industrial leaders and have lost their rank as a result of high labor costs, shorter work weeks, high social program cost, and general arrogance. The methods we are now asked to embrace were not methods developed from success but those of cultural habit that was necessary in the era of the industrial revolution and represent impracticality in today's environment. ISO standards are one of the reasons Asia is gaining on the West...and not because they comply! Best Regards,Michael O'Brien President Signature Technologies As an employee in the Engineering Department of a company that has been ISO 9001 certified for six years, I very much enjoyed your article "ISO 9000 Backlash" in Embedded Systems Programming, June 2002 issue. It validated my own feelings of frustration over an effort that I felt drained our resources and simply lowered our productivity. For the last 2-1/2 years, we have been under a major U.S. corporation, and are beginning to feel the smothering effects of Six Sigma - a concept that I would put in the same class as Communism (i.e. looks good on paper....). The expenditure of time, personnel and money toward this cause has had six times the resource-draining effect that ISO 9000 ever had. Projects, meetings, emails, Black Belts, Green Belts, promotions, ceremonies, contests, financial calculations conjured up to justify projects launched simply to certify people - it's like a constant running of "We didn't Start the Fire". And all done with the mystic of religious ceremony. If Murphy's Law ever tackles Six Sigma, let me know - I'd enjoy the benefit of someone else's perspective. Jeff Behuniak I have worked for two companies where it worked well. Mass Consultants (www.mass.co.uk) and Hunting Engineering (now Insys www.insys-ltd.co.uk) both moved from AQAP, the Allied Quality Assurance Program to ISO at the behest of the military. AQAP was much more pragmatic. ISO can be very dogmatic and this can lead to processes which are worse than useless. An interesting thing at Hunting was that the software quality department was about six folks for 800 engineers and technical staff, in Mass it was 2 of 50. As one of the team
leaders I wrote some of the standards we used and contributed
to others. When we had something that didn't work we had it modified.
The actual overheads are not onerous. Now in the US I see companies
that try to apply ISO to what they already do, however they aren't
working in an effective way to begin with. As an example, your
state that the titles in the design document table of contents
are inadequate. Well, our table of contents included the first
three levels of heading, so we had no problem making it useful.
For example: Introduction We also designed in UML, so the design document was a wordy description of what was actually detailed in the UML. So now the top level titles don't matter. They never did. You were never constrained to use only the ones given. For us ISO was a way of measuring the quality we already had, it was a bit different but not a lot. Most of the companies I have seen in the US see quality as a cost rather than a benefit, something that has to be paid for and can be added on. You either build it in or you may as well not bother, you can't apply it afterwards, that's like using shingles to hold your roof together. In the UK we lived the quality system, it was just the way we worked. Five minutes to fill out a fault report for a bug that took six hours to find and fix is nothing. Our first ISO auditor was the UK MoD and the second was Lloyds of London, Lloyds were more pragmatic. Chris Hann This article was forwarded to me by one of OTBU directors. http://www.embedded.com/story/OEG20020524S0080. As a quality professional (Software Test Engineer) I have to disagree with some of your generalizations about the ISO 9000 quality standards. First of all, the new standards, ISO 9000:2000 requires less documentation than the 1994 version. ISO is not designed to make more work for engineers, it's a business management system. How it is implemented depends on how the employees perceive its value. Other quality standards that apply to software, like IEEE, CMM model, TL 9000 for telecommunications, Bellcore TR-179, ISO 9000-3-1997 are based on the same quality principals, customer focus, leadership, process approach, continual improvement, etc., as ISO 9000. ISO 9000:2000 is a process approach when developing, implementing and improving the effectiveness of a quality management system. The intent of this process approach is to enhance customer satisfaction The success of the program depends on the one making the evaluation- the ISO auditor. So I think the real question is who audits the auditors? How are they held accountable for the quality of the companies they register? Can ISO certification be bought by companies who pay enough or sign lengthy contract agreements with the RAB auditors? Yes. In conclusion, I would suggest comparing ISO to FDA requirements, then decide if the standards are really over bearing or document intensive. Anyone who has worked in an FDA environment would say ISO compliance is a walk in the park compared to obtaining FDA approval for medical devices. That's just my opinion. I enjoy your articles. Thanks for listening. Stacy Apostol Thanks for your feedback. While you make some good points, I would like to pick you up on two of them. "The success of the program depends on the one making the evaluation- the ISO auditor" This is the core of the problem with ISO 9000 - it is auditor based. If a team adapts ISO and tries to follow its lead, and an audit follows 6 months later, it is too late to make dramatic change. Also entrusting such an amount of power of veto to an outside auditor can completely demoralise the team. The second point is about the FDA - while the FDA proceedures are by no means perfect, there is a fundemental difference in the motivation for an FDA audit. The FDA manage a certain set of industries, and have legal obligations to gate entry to those markets. If you are not in those marketsm then the FDA will not be involved. ISO 9000 tries to market itself to everyone possible, as a better way of doing business - there is commercial advantage to bringing in a new client. While the FDA has no commercial motivation to pass or fail or encourage anyone. regards, When I read your column in this month's ESP, I couldn't believe my eyes! You gotta love free press--even in the technical world! :) I just want to say that you hit the nail on the head--with a 15 lb. sledgehammer. Go Niall! I have oft asked myself a question when I see companies touting their ISO9000 certification. And that question is: "Knowing what ISO9000 has done at my company and previous employers, do I think that the product I am considering purchase of is better, the same, or worse than similar products from a non-ISO9000 company?" Without fail, the answer to this question is usually the same or worse--and consequently I buy the non-ISO product. Why? It tends to be cheaper and as good or better than the ISO9000 certified company's product. The word 'Quality' is such an over-used word in corporate America that it's real meaning becomes worthless. Kind of like the boy who cried wolf. I have worked at several large corporations (Martin Marietta for example) and in each case when engineers talk about quality, they have contempt and disgust in their emotions because 'Quality' to them is the organization that: 1) hinders them from putting out quality documents, true quality software and hardware 2) causes them to be behind schedule 3) creates a lot of totally useless paperwork. For example, 'interface control documents' that are basically the actual code without syntax. Why not just ensure the code itself is REALLY properly commented and let the code be 'self-documented'. It is a waste of time and money to have engineers making $60K and up cut and pasting code into a Word document. This is a sad joke indeed. 4) make them kiss the a** of 'Quality Engineers' to get their signatures, when the Quality engineers have NEVER designed, coded or written a program themselves or designed a working piece of hardware. I have NEVER encountered a SW Quality Engineer that could actually design, code, debug and integrate an application or even write a simple "Hello World" program. How can people be so assanine to think that someone totally foreign to the process and products they are quality engineers on, can actually improve the quality of that product? I hold the belief that whomever came up with ISO9000 must be the greatest con-artists of all time. Think about it. Pay me a tens of thousands of dollars and I'll come and 'audit' your company according to my nebulous criteria for quality (ie. Is everything documented?) and then I'll give you a pretty plaque to hang on your lobby wall and allow you to advertise compliance with my standard. But it doesn't stop here, I'll have to audit you on a regular basis and that'll cost you another few thousand dollars.... Now why didn't I think of THAT!!! Unlike you in your 'freedome of the press' armor, I am not immune to retribution, so please if you print/publish my letter on the Internet or in the magazine, please withhold my name and address. Niall replies Thanks for your feedback - on your last point about "Freedom of the press", I have no doubt that at some point I will apply for a contract and will meet resistance from someone who has read what I wrote about ISO 9000, and they will say "Keep this guy out, he is going to spend the whole time fighting against our quality system." However that is a chance I am prepared to take. In my view, this article reflects a general misunderstanding in the industry of ISO9000 rather than the value of the standard. It is probably based on a combination of poor implementation experiences, a general dislike of documentation and good old resistance to change ("I've been doing just fine the last 10 years without this bureaucratic @#$%"). In my view, the problem does not lie with ISO9000; it is a very non-prescriptive document, focussing on principles as opposed to implementation. This view is confirmed by the positive experience testimony quoted; here we should note the critical issue - the software team designed the process. We did just that, asking the embedded team to write their own procedure from scratch. Yes, we did "temper" it a little with some quality management principles, but it was 90% theirs. We were subsequently ISO9000:2000 certified and they don't have the barriers you describe. I believe the bad experiences are largely related to folks incorrectly assuming that traditional "QC" paper trails are the only way to design a quality management system. The perceived inflexibility is also easily solved; we did so by introducing a checklist at the beginning of the project where the project team (all disciplines) agrees which of the standard set of deliverables are required for the project. We have one discussion and its done; no pain, no delays. The "reds in the bed" rant is, in my view, faulty logic and could quite easily be turned around. I think the track record of our industry confirms that we need to look long and had about better ways to do things; in our company, ISO9000 helped us do just that. Alan Wagner, Pr Eng
Product Design Manager Excellent article. You are 100% correct. The ISO procedures are implemented by those not doing the work. The people doing the work are too busy to worry about ISO9000. A group that communicates regularly, (often for us with an quick meeting in the lab) gets the job done sooner. Marketing's claim to "ISO9000 will increased sales" has never materialized. In fact, generally our better sales are going to the small customers who could care less about the ISO9000 system. A good solid design should be the investment, not paperwork that says you tried and failed. Regards. Dear Niall, Having read your articles and the feedback from them it seems to me that you could boil down the Quality and ISO 9000 arguments very simply. The point of ISO 9000 is to describe how your company gets quality into its products. Can we say that any given software project is going to produce a result which has minimal bugs and meets the customer's requirements? If we talk to the customer we will get an idea of the requirements and we should document them so both sides a can agree on what is to be produced. We need some idea on how to get there so some sort of design document is required. If we are providing external interfaces then we need to have some sort of "working" document that we can publish to third parties so that work can be done elsewhere. This document does need to change and everybody kept informed at regular intervals. Similarly, within a group of software engineers working on the same project, each needs to know how the others bit reacts and interacts with theirs - this may be documented formally - but at the very least some sort of record needs to be kept when changes are made so we can back track if bugs are found and know when bugs are fixed. Finally, we need some way of testing what we've done and saying so. If we know x was tested and it worked on one date and then didn't work later we can conclude that we've introduced a bug between these dates, otherwise we are down to playing guessing games. Having described this as the way of sensibly going about a software project that most software engineers could relate to, I can't see why this wouldn't get you an ISO 9000 certification. These are the things you need to do anyway. Perhaps thats the point. It seems that too many of the procedures in the real world have been written by people who want to know what you've done and want control over what is going on and are using ISO 9000 certification as the weapon of choice to enforce this control. Its not about quality, its about control. Lets face it, managers and marketing have never understood software or software engineers. If we didn't have what they need we'd be burned at the stake. I have only been subjected to documentation mania once. Many years ago I was working for company which was designing some networking systems for American Airlines. There were Requirments Documents, Software Requirements, Software Design Requirements, Software Design, Software Module Design, and probably some others that I've forgotton. After over a year of documents being produced and delivered, AA were quite interested in seeing some code being written. Even a demo version would have been nice (but it would have had to have been documented so it never happened). At the lowest level you had to write up, in pseudo code, how each module, function and procedure operated. Even these were a deliverable documents. The amusing thing from my perspective was that the pseudo code had its own definition document. You had to write your code according to this document. Having done so you could then write the actual code. Cunningly enough, the company had made this easier by writing a psuedo code parser that would write your code files for you. .I argued, with a moderate amount of success, that pseudo code was meant to be a rough outline of the code in a near english fashion in order to get understand what a module had to do.. What the company had done was define a new language. What we now needed was a pseudo pseudo code. Presumeably the company would have then codified this and we'd go around the circle again. (Maybe it would have understod english by now?). I did get the use of the formalised pseudo code dropped for our part of the project... we may even have made the deadlines had the company not gone into administration. I shall look forward to more on the subject of ISO 9000 and Quality. It looks like it'll run and run. Regards I worked for two companies who went down the quality programme route, one for good reasons, the other for no good reason. I worked for a small British defence consultancy that implemented ISO9000. There were a lot of good things that came out of the process, but lots of stupidity too. Good things were an increased emphasis on process and documentation. Bad things were an increase in documentation and some absurdities. I ended up writing some documents that we all knew no-one would ever read, but on the whole this wasn't too bad. The auditors implemented some real stupidity. The company almost failed it's audit on stupid things, for example there was a board giving the status of the minicomputers, on the list was the name of a computer that had been scrapped, the auditors told us the name had to be removed, so the support staff ended up spending time on trivia like this. Because the company had sound business reasons to go for ISO 9000 and was small, the stupidity was kept to a minimum and was solely auditor inspired. The real hell was CMM. This is the Capability Maturity Model. The next (very big) company I worked for suffered from weak management (all over) and poor engineering (in parts). So they decided to go for CMM. This was ISO 9000 on steroids. I have never seen such stupidity. At one stage I was asked to supply 30 documents for an engineering project that would take one person (me) two months. We were asked to jump through hoops to achieve the eventual nirvana of level 3 (which we never did). To be honest, some of the stuff we were asked to do was sensible, but the rest was nonsense. The overhead was massive, I ended up spending one day a week on the CMM activities for that week. The stated aim was to improve project predictability and to reduce the number of bugs. What was interesting was the scale of the failure of CMM. It increased project time by 25%, but did improve predictability. The number of bugs found decreased, but that was probably due to the fact that the number of releases fell off dramatically. Teams just weren't as productive. We had a target to spend no more than 10% of project time on CMM, but some projects hit 50%. The beginning of the end occurred when management decreed that time spent on CMM training was not to be booked to CMM. Shortly after, there was a large meeting where 300 engineers were told we had met the requirements for CMM level 1. The sound of 300 engineers not clapping was deafening. Management was shocked at the extent of the lack of buy in. Eventually senior management got fed up of this nonsense and the CMM project was sidelined. Some of the sharper CMM players saw the change coming and jumped ship beforehand. It was gratifying to see it all end, but I would have preferred to have seen people punished for their stupidity, but of course they weren't. I think I now understand why some quality projects work and some don't. The failure I saw was because 2nd rate people saw a new thing and jumped on the band wagon. They used it to further their careers and establish a power base. There was insufficient management oversight of what they were doing (who audits the auditors), so they got away with it. After these experiences, I think I know what leads to a successful project. Good management and good employees. ISO9000 and CMM are neither here nor there. Mike Woodward |
|
|