Selecting the Right Standard (former ISO 9000 thread)

[Guy McDonald <guy -at- NWLINK -dot- COM>]

Ralph Robinson raised the Quality ensign once again with the following...

"It is really interesting to see the perceptions of the members of
this list regarding this standard, very few of which indicate they
have any direct involvement with ISO.

Generally speaking, the companies or organizations that belittle ISO
9000 and all things so related have either implemented ISO poorly, or
for the wrong reasons, or _both_.  One respondent was quite correct
in stating that ISO 9000 has nothing to do with quality!!  It _does_
have everything to do with managing business processes that affect
product/service quality so that consistency and repeatability are
achieved, hopefully at a high level of product/service quality.

<snip>

Any thoughts that ISO 9000 is just a 'fad' that will disappear in the
near future should be quickly dispelled, and anyone thinking that way
will go the way of the dinosaur.  ISO is a fact of business life.  It
will become more important to successful businesses;  it does work;
companies do change and get better because of it; and it will _not_ go
away!!"
--------------------

My research on various SDLC quality standards led me to agree with Ralph's
basic philosophy - quality is an attitudinal aspect of a learning
organization, not a function of blind obeisance to the writings etched out
on stone tablets.  Several months ago, I asked some QA professionals working
in the IT field to provide opinions on which standards worked best for them.
The responses were not what I expected.

It is clear to me that no one standard is the "best fit" for any company.
There are those who have tied their anchors to one particular standard [ISO
9000, et. al] that may quickly point out that one standard can address
almost any set of circumstances.  I find it prudent to spend money up front
with organizational assessment during the planning phase - then build the
right program, rather than buy the farm later with a bad bill of sale.
Therefore, it is befitting for the technical communication community to
examine lessons learned by others, such as the programmers at IBM.  All of
this should be done before we march willy-nilly down undesirable paths.

For Ralph, and the rest of you watching this thread with interest, I have
attached a short excerpt of a piece I wrote (with references culled out of
my bibliography) that speaks to the aforementioned issue.

Guy McDonald
guy -at- nwlink -dot- com
--------------------------------

"All is flux, nothing stays still. Nothing endures but change"
Heraclitus, cir. 540-480 B.C.

For the past several decades, industry has relied upon complex management
programs to help improve product quality.  Within each program, quality
control standards are used to reach the nirvana called "near perfection."
Standards such as IEEE, DOD and ISO have been used by organizations in the
hopes that quality  will improve to meet customer satisfaction.  Ironically
in some cases, the exact opposite occurs!

There is no one true real model by which we should tailor our quality
programs, especially when it comes to selecting standards.  Each program has
what some may consider flaws, limitations, or shortcomings.  On the other
hand, others may not consider the very same shortcomings negatively, but
rather as incontestable truths.  Therefore, the perspective disagreement
lies not in familiar arguments, which tout the miscellaneous variances
between standards, but with the individual needs of a particular
organization.

"So many managers rushed immediately for ISO 9000 certification, just as
they have grasped for every other quality initiative that has come along;
everything from Total Quality Management (TQM) to Statistical Process
Control, Deming, Juran, Crosby, Zero-Defects, and others. It is not the
quality they seek, but the perceived market advantage signified by the
certification. It is the paper they want to hang on their wall, not
development of quality products for their customers."  (Staff, March/April
1996)

Industry is slowly shifting towards a nontraditional approach to quality
improvement and away from following a set of rules written in stone.  In
1990, IBM introduced methods based on empowering programming development
teams, guided by a set of principles [standards] defined by the programming
community and driven by aggressive goals established to improve quality and
enhance customer satisfaction.  This led to a set of good programming
routines that were shared across the programming community in IBM.  The
result has not only been a dramatic improvement in the quality of IBM's
program products, but also the fostering of a work environment based on
creativity and excellence that engenders pride of ownership for work
performed.

Through the years, the number of program defects in IBM products declined,
but by 1988 the rate had only improved by a factor of two from what it was
10 years before, and that was on a relative basis. (Ganek, 1993)  So how did
IBM break free from a quality assurance quagmire?  IBM-funded two studies to
help break the barrier.

The first, called the "best of breed" study, was performed internally and
completed in April, 1989. It looked at 35 projects from 19 different IBM
laboratories. Characteristics of these projects were short cycle times, high
productivity, large amounts of code reuse or porting, excellent reliability
or performance, improved usability, etc.

The second was a consultant study, completed in June 1989, that looked at
development processes, methods, and tools of 11 other companies.
(IBM-funded study, June, 1989)  The conclusions of this study were
essentially identical to those of the first one.  Another study of six
Japanese computer manufacturers later confirmed the results of the first two
studies, as did a number of "benchmarks" performed by IBM programming teams.
(IBM-funded study, October, 1990)

From these findings a list of 12 "principles" was published in August 1990
and serves as the primary guidance for programming development in IBM.  The
principles represent nothing new separately.  However, taken collectively
they provide an effective framework for programming development.  Therefore,
it is with the establishment of some formal methodology that a manager can
overcome corporate fear of change.  Moreover, it is by team involvement
during the selection and refinement process of this standard selection, that
collective and individual fears diminish through empowerment.   Whether the
methodology conforms to standards outlined in the Malcolm Baldrige National
Quality Award, ISO 9000, the SEI Capability Maturity Model, IEEE, DOD, etc.,
the agreed upon standards (or subsequent derivation) should be used by an
organization.  There must be a consistent basis for comparisons and
improvement to facilitate quality assurance program growth.

Managers who desire to establish standards that every member of the
organization will follow are cognizant that all concerned will experience a
daily struggle.  This battle centers on realizing goal accomplishment while
meeting the intent of the program.  As mentioned earlier, people resist
changes... especially those that implement quality standards into everyday
work practices!  To overcome what is often construed as a threat to comfort
and stability, the manager must address the education process by which every
employee is subjected during standard implementation.

The transition of the IBM programming community from an environment of
classical mechanistic management to one based on empowerment provided
programming developers with the opportunity to achieve IBM's quality
assurance goals in software products. A framework based on proven principles
was developed which led to a number of good programming practices that are
now shared across the community. Consequently, a renewed spirit of pride in
ownership maturated as well as a marked improvement in essential
measurements of product quality.

Project managers who encourage departmental buy-in at the planning stage
when quality standards are established, can expect appreciable production
results from cycle to cycle.  Otherwise, the company may flounder in a
vacuum of stagnation, apathy and frustration... regardless of how well
intentioned the individual and/or collective effort.  As Richard C. Buetow,
Motorola Director of Corporate Quality said, "with ISO 9000 you can still
have terrible processes and products. You can certify a manufacturer that
makes life jackets from concrete, as long as those jackets are made
according to the documented procedures, and the company provides the next of
kin with instructions on how to complain about defects."  (Staff,
March/April 1996)

REFERENCES

Ganek, A. G., (1993, March 9). Presentation to GUIDE Board of Directors,
Anaheim, CA.
Heraclitus, Diogenes Laertius, bk. IX, sec. 8. In J. Bartlett & E.M. Beck
(Eds.), Familiar Quotations, Vol. 14, (p. 77). Boston, MA: Little, Brown and
Company.
IBM-funded study (1989, June).  SRI International, 11 U.S. data processing
companies.
IBM-funded study, (1990, October). SRI International, 6 Japanese data
processing companies.
Staff. (1996, March/April). Let's Put the Emphasis Back Where It Belongs -
On Actual Product Quality vs. ISO 9000 Certification. Program Manager, 25,
p. 42-51.