Feedback to "ISO 9000 Backlash"- Murphy's Law, January
Read the original artilce at ISO
return to Murphy's Law
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
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
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
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
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.
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
__ Power on BIT
_ Operational Software
__ Power on
__ Event handling
__ System monitoring
__ Autopilot Arming
__ system interface
__ Messaging subsystem
_ External Interfaces
__ Serial Debug
__ Analog in
__ Digital in
__ Digital out
ANNEX A UML Design
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
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
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.
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.
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
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
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.
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,
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
Merlin Gerin SA (Pty) Ltd t/a Conlog
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
Jeff Kaiser Technical Team Leader
Transmission Development Engineering
Charles Industries, Ltd.
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
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.
Roderick M Main, Senior Software Engineer
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
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.