Effective Engineering e-Newsletter – 5/5/2005
This is your monthly e-Newsletter from Effective Engineering Consulting
Services (www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as
they are published, please send an email to e-newsletter@effectiveeng.com,
and we will add you to our distribution list.
Comments and suggestions are welcome and encouraged!
eN-050505:
Make Quality a Full Member of Your Team!
By
Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
Over the 35+ years of my career in engineering product development,
I’ve been involved in a wide variety of development teams.
The team efforts have included software, firmware, hardware, and
mechanical developments. The
projects have been small, medium, large, and very large.
The people involved have had incredibly diverse backgrounds and
experiences. Most of those teams
have been successful with excellent people in all sizes of development teams.
Some of those teams have been less successful, and while I’m
reluctant to generalize, I believe it’s safe to say that those teams where
quality was viewed as essential were far more successful than those where
quality was viewed as “nice to have” but not essential.
Quality can never be considered “nice to have”; it must be an
essential requirement in any product development effort.
This applies to quality in the abstract, to quality as a function in
the organization, and to all of the individuals who help to ensure that
quality is designed into every product a company sells (see also eN-021205
– Poor Quality Products Imply A Poor Quality Company and eN-041007
– Quality By Design!).
In the abstract, everyone will agree that quality is good, like motherhood and
apple pie. Who could be against
quality? What company has ever
said they don’t deliver quality products?
Yet if you look back at the American car industry before the higher
quality Japanese cars began taking significant market share, it’s safe to
say that quality was not a strong consideration in American car making.
However, only by comparison with something much better did this really
become evident. As a consequence
of dwindling sales and needing to be able to effectively compete, American
carmakers started paying more attention to quality, and even delivered mottos
such as, “Quality Is Job One”. Only
after being smacked in the face with it did American carmakers recognized the
absolute need to make quality a key member of their team.
Most companies now take quality seriously, or at least somewhat seriously. They typically have quality groups in the company – quality
assurance or quality control. They
invest in quality training, and often seek to become quality certified (e.g.
ISO 9000 certification). These
are good signs.
Within development organizations there are often quality departments or
quality groups, depending upon the size of the organization.
These groups are tasked with verifying the quality of the products the
company is developing, and identifying problems before they reach the field
(see also eN-040610
– Development Methodology: Test – to Verify).
In better companies these quality groups are fully integrated into the
team, and are viewed as full members of the team whose contributions are
recognized as critical and important. Their
job is to work closely with the developers to ensure a quality product is
developed and delivered to them, and to verify the quality of that delivered
product. They work closely and
cooperatively with developers as co-equals who help each other, and help
ensure the products meet the high quality levels the company demands and that
customers expect.
In some organizations, typically those where quality is viewed as “nice to
have”, the quality groups are tasked with attempting to “inspect quality
into the products”. This generally does not work.
The attitude is that it is not really the responsibility of the
developers to deliver quality product, but the responsibility of the quality
group to find what’s wrong with the developer’s work, and to let the
developers know so they can fix it. The
developers’ work is typically “thrown over the wall” to the quality
group to test pretty much in a vacuum. In
these situations, quality is not a member of the team; quality is an outlier
group that is there only to check out the work of the “real” team members
– the developers. In such
organizations, the quality group members are often viewed as outsiders, who
are “servants” to the developers, and are often looked down upon as
second-class citizens (“Those who can, develop; those who can’t, test”).
The developers often resent them for finding bugs in their
“perfect” products (in some cases, they will try to re-define a bug as a
“feature” so they don’t need to “fix” it).
The developer’s arrogance can sometimes be breathtaking, and the
damage they do can be enormous (see eN-031120
– Herding Cats: Management Challenges 1 – The Elitist
Bastard). Much of this is
arrogance out of ignorance, and refusing to recognize the contributions that
others can provide to ensure that “good” products get released to the
field. The quality group members resent being viewed as second-class
citizens, and little camaraderie or cooperation results.
In the extreme, the two groups will work at cross-purposes, to the
detriment of the product and the company.
Such attitudes are corrosive and self-defeating, and result in the
delivery of products that generally are not of high quality, and that
customers learn to hate.
Make your organization and company a successful one.
In order to succeed, it is necessary to recognize quality as an
essential element of any product development effort.
It can make or break a product launch (you only get one chance to make
a good first impression!), and prosperous ongoing sales.
Embrace Quality – the concept, the function, and the people.
Make Quality a full member of your team!
Copyright ©
2005 Effective Engineering Consulting Services, All Rights Reserved
