| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1225.1 | | BAGELS::CARROLL | | Thu Oct 11 1990 19:31 | 3 |
| I agree. I see no emphasis placed on quality. Saving money will not
sell out products, only quality will. Quality the first time, not
after "a customer screams", which is how quality is done today.
|
| 1225.2 | Do the job right the 1st time around! | SHRCAL::MORRILL | | Thu Oct 11 1990 22:54 | 20 |
|
I also agree that quality is a serious issue. Engineering and
manufacturing areas should take more care to ensure the accuracy of the
tools they use in the development and production of thier product.
In my 7 years in DEC Calibration Labs, I have seen more equipment
disasters than I care to admit. The worst part is that when budget
cuts are necessary, equipment maintenance and calibration is among the
first to get the ax.
The whole point is that we (as a corporation) need to develope and
produce first class products the first time. To do that we need to
utilize ALL of our assets in the best possible ways. It is an
expensive proposition, but it is far cheaper than doing the job over
because of bogus test results or doing the fire fighter detail in the
field.
Quality products start in the workplace, not on the budget cutting
board. As they say at FORD, Quality is JOB #1.
|
| 1225.3 | IBM/Rochester wins Malcolm Baldridge Quality Award | JAWJA::GRESH | Subtle as a Brick | Fri Oct 12 1990 11:16 | 60 |
|
----- IBM Rochester wins top U.S. quality
|C I S| award
-----
Source : Business Wire Date : 11-OCT-90
ARMONK, N.Y.--(BUSINESS WIRE)--IBM Rochester, Minn., was awarded
the federal government's highest quality honor Wednesday, capturing the
Malcolm Baldrige National Quality Award.
The large Minnesota facility, home of the AS/400 family of
computers and advanced direct access storage products, won for the
combined excellence of all of its operations.
IBM Chairman John F. Akers congratulated the employees at
Rochester whose daily work helped earn the Baldrige distinction.
``I salute our general manager, Larry Osterwise, and each and
every one of our IBM colleagues in Rochester,'' Akers said. ``It
took the energy and conviction of the whole team, all pulling
together, to earn this award.''
Rochester leads the implementation of IBM's market-driven quality
efforts and will stand as a model in the company's drive to achieve
total customer satisfaction.
``As proud and happy as we are,'' Akers said, ``we regard the
Baldrige Award as a promising signpost rather than an end in itself.
The work only begins here. The Rochester experience confirms our
belief that we are on the right course.''
Akers also had words of praise for the award competition, named
for the late Secretary of Commerce Malcolm Baldrige. ``The Baldrige
Award has helped to rally business around a common objective. More
than ever, quality is the key to competing effectively in global
markets.''
Stephen B. Schwartz, named as IBM's lead quality executive in
April, previously led IBM Application Business Systems. Rochester is
the unit's principal development and manufacturing facility.
Schwartz said, ``With our focus on market-driven quality, IBM is
using the Baldrige assessment discipline throughout the corporation
so that our own view of what defines quality is buttressed by an
objective, external standard. That puts IBM more in tune with our
customers and suppliers.''
The AS/400, introduced in June of 1988 and developed in half the
time of its predecessor, helped to pilot IBM's market-driven quality
process. IBM involved hundreds of customers, independent software
vendors and suppliers in all aspects of the product, from design to
delivery.
``IBM Rochester's experience is that quality pays,'' Schwartz
said. ``Reduced cycle times mean we are getting products to market
faster. Defect elimination means fewer service calls and lower
warranty payments. And satisfied customers mean more business.
Quality is the single most effective way to improve the performance
of the company over the long term.''
|
| 1225.4 | Pay more - Get more | COOKIE::LENNARD | | Fri Oct 12 1990 15:06 | 9 |
| Face it troops...as a national entity we are not quality oriented...
and we do not value quality. Look at our trashy cars, fly-by-night
building contractors, sloppy public servants, K-Mart mentality, etc.
Should it be a surprise that our designers, developers and managers
feel the same way? We love to talk about quality, but we aren't
willing to pay for it. We still don't seem to understand that
typically the best quality/more expensive product is in the long
run the best buy.
|
| 1225.5 | Six-Sigma...1 fault in a Million | SHRCAL::MORRILL | | Fri Oct 12 1990 16:13 | 20 |
|
RE: .4
>We love to talk quality, but we aren't willing to pay for it. We
>still don't seem to understand that typically, the best quality/more
>expensive product is in the long run the best buy.
Well Put. In The Standards Labs and Calibration Departments in
this corporation, the expirtise and attention to quality is not only an
issue, it is A WAY OF LIFE. The reason behind this is because
Calibration Personnel are generally perfectionists. We are often
criticised for following all the government and DEC specs, but we all
have the personnal integrity to continue doing things right and not cut
the corners at the expense of quality.
My Calibration Lab has not had a single return for poor workmanship
or error in it's entire history. How many other "Outside labs" can say
that...The data I have gathered indicates not very many.
Quality service takes both time and funding...but you get the best
results.
|
| 1225.6 | $ $ $ $ | CGOA01::DTHOMPSON | Don, of Don's ACT | Fri Oct 12 1990 21:07 | 9 |
| re: .4
'Tain't a dislike for quality, 'tis...
The Love of Money.
What a novel surprise.
|
| 1225.7 | | SA1794::CHARBONND | scorn to trade my place | Mon Oct 15 1990 09:46 | 14 |
| re .5 Six-Sigma is 3.4 flaws per million.
re .6 >'tis...The Love of Money
Not exactly. It's the love of the short-term profit, although the
long-term may be disastrous. This doesn't start at the corporate
level. It starts at Wall Street, where nobody gives a damn about
anything further away than the next quarterly earnings report.
(Witness DEC trading at $20 lower than book value. Short-sightedness
at it's most blatant.) Corporations *react* to this by blowing off
quality in an effort to get product out the door ASAP, quality of
design and manufacture be damned. Gotta get those numbers up.
Reputation for quality ? Who cares. We react to Wall Street, *not*
to the customers.
|
| 1225.8 | THE DIGITAL VISION | NBOIS2::BLUNK | Bruce P. Blunk NBO | Mon Oct 15 1990 11:40 | 72 |
| 1225.9 | Just a repeat of all that's been said before | SMOOT::ROTH | Iraq needs lawyers... send some NOW!! | Mon Oct 15 1990 14:02 | 29 |
|
The biblical quote "Without vision the people perish" has been
scattered throughout this conference lately... and I think that
best sums things up.
Digital's employees will need to be *LED* in a quest for quality,
trying to *MANAGE* them will not do. I don't believe that the quest
for quality in-and-of-itself is enough to pull us out of our spin.
Many leaders/dreamers up and down the digital management/employee
chain have had their desire and determination reduced to
frustration and bitterness by self-centered politicians in the
management chain above them. I'd venture a guess that 60-75% of
Digital's employees are (or could be) leaders and/or dreamers. I'd
certainly classify myself as one.
The Kinzelman memo hits square on the head the current management
situation. Steps must be taken in these areas if employee
confidence is to be restored. To believe that we can achieve the
desired quality with a demoralized and demotivated workforce is a
serious mistake. As to how many and to what degree DEC employees
are demoralized and demotivated is left as an exercise to the
reader, but I certainly feel that it is not uncommon.
It will take LEADERSHIP to restore our vision and set our course.
If we can renew the vision of our leaders and dreamers everywhere
then we have a chance to succeed- without them we have none.
Lee
|
| 1225.10 | "Eliminate Management by Slogan!" -- ZK1 entrance barcodes | TLE::AMARTIN | Alan H. Martin | Tue Oct 16 1990 13:19 | 17 |
| 1225.11 | Next reply (after this) is rather long | BIGUN::ANDERSON | The Unbearable Lightness of Being | Wed Oct 17 1990 07:27 | 1 |
| Some interesting comments on the Japanese and QA follow in the next reply...
|
| 1225.12 | Japanese Software Industry - "How to Beat Americans"??? | BIGUN::ANDERSON | The Unbearable Lightness of Being | Wed Oct 17 1990 07:28 | 800 |
|
I N T E R O F F I C E M E M O R A N D U M
Date: 11-Jul-1990 03:38pm GMT
From: VMSMail User JBRADY
JBRADY@ESSB@MRGATE
Dept:
Tel No:
TO: JBRADY@ESSB@MRGATE
Subject: Japanese Software Industry
From: GALVIA::PLUNKETT "Jack Plunkett, Documentation and Design. 890-2133
10-Jul-1990 1623" 10-JUL-1990 16:26:00.96
To: @DIST_STAFF
CC: ESSB::JCUNNINGHAM
Subj: Japanese software industry
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | I n t e r o f f i c e M e m o r a n d u m
| | | | | | | |
+---------------------------+
To: Distribution Date: 10 July 1990
From: Chip Nylander
Dept: Software Development
Technologies
DTN.: 381-2057 Loc.: ZK 2-3/N30
File: JAPAN-SOFTWARE-9006
Rev.: 0
Subj: Report -- USAF Japan Software Meeting 6/26/90
1 EXECUTIVE SUMMARY
The USAF/High Leverage Technology office sponsored a 1 day national
briefing to discuss the current state and methods of Japanese software
development, and the competitive threat they pose. This meeting was
attended by about 60 leaders from corporate, academic, and research
institutions.
This meeting was provoked by information formally presented and
informally gathered at the First and Second International Workshop on
Software Quality Improvement, held in Japan in 1989 and 1990. (The
Third International Workshop will be held in Tokyo in 1/91).
The participants agreed on the problem (cause and effect), but not on
solutions (followup or actions). Little at this meeting seemed
surprising or new; this is probably a testimony to how effective
Digital has been at getting Japanese awareness into the corporation.
However, it was significant and sobering to get all the information in
one place at one time, and there are lessons for Digital software
development.
The participants agreed that the Japanese are out-engineering the rest
of the world in software cost and quality. The cause of this is not
software development technology. It is software development
management, and treating software as a business to be managed.
Japan has not discovered any technological "magic bullet", and there
is no magic in their software factories. "Software Factory" equals
"Production approach plus effective software development management".
Report -- USAF Japan Software Meeting 6/26/90 Page 2
EXECUTIVE SUMMARY
Their success is based on
1. An emphasis on management of the software development
process.
2. Use of simple proven technology, not development of new
technology.
3. Planned, realistic productivity and quality goals.
4. Productivity and quality metrics, meticulously applied to
assess progress towards goals.
5. Incremental, relentless improvement.
6. A high level of process maturity.
7. Strong company orientation, corporate team focus.
8. Strong problem solving orientation.
9. Reward systems and competition between teams based on
measured productivity, quality, and progress, not on charter
and turf.
10. Strong internal corporate training programs and emphasis on
human improvement.
11. Involvement in quality and productivity improvement from the
CEO down.
In addition, innovative U.S. technology (including software
technology) is moving to Japan because the Japanese are much more
opportunistic in funding promising new technologies for future use,
which they will aggressively adopt when proven.
The "decision cycle" in the U.S. is much longer than in Japan,
leading many under-funded U.S. technology start-ups to obtain capital
by selling the technology to Japan.
This meeting suggested numerous possible lessons for Digital,
including
1. Improvements in productivity and quality have to be planned.
Improvement is unlikely without defining long term goals,
backed up by near term attainable/measureable goals.
2. Higher levels of software development productivity and
quality can be produced with current technology, fully
applying simple-to-use tools before upgrading to more
sophisticated technology.
Report -- USAF Japan Software Meeting 6/26/90 Page 3
EXECUTIVE SUMMARY
3. Higher levels of software development productivity and
quality can be produced via human improvement through
training and management.
4. Feedback and incremental improvement are critical -- don't
look for quantum leaps.
5. Measurement is critical to continual improvement.
6. Patience, endurance, and organizational stability are
necessary to implement, track, and manage incremental
progress.
7. Don't insist on absolute "scientific" measures of quality; do
measure trends in indicators of quality improvement (even if
the metrics seem "nonsensical").
8. Quality and productivity must be high priorities to senior
management.
9. Digital (and the U.S. in general) can benefit by "stealing"
all the work Japan has done in applying quality and
productivity improvement to their software, and apply it to
our own software.
The remainder of this memo documents the context, attendees, and
content of this meeting in more detail.
2 SOURCES FOR ADDITIONAL INFORMATION
The Third International Workshop on Software Quality Improvement will
be held in Tokyo January 21 - January 26, 1991, and is open to
participation by Digital. Additional information can be had from
Professor Victor Basili, Department of Computer Science, University of
Maryland, College Park, MD 20704; email: basili@cs.umd.edu.
Michael Cusumano has published a series of MIT Industrial Liaison
Program reports, describing the Japanese Software Factories and
software development management and methods. These papers are
available through the Digital library DLN system.
This autumn, Oxford University Press will be publishing Cusumano's
"Japan's Software Factories: A Challenge to U.S. Management".
The Japanese are heavy users of "Managing the Software Process", by
Watt S. Humphrey. Well-worn copies of this book are reportedly
common in the offices of Japanese software managers.
Report -- USAF Japan Software Meeting 6/26/90 Page 4
CONTEXT
3 CONTEXT
In June, Colonel Will Stackhouse, Asst. for High Leverage Technology,
sent a FAX to numerous high-level software executives, researchers,
and technologists which read, in part:
Contrary to popular opinion the United States is no
longer dominant in software and whatever lead we may
have is rapidly eroding.
Knowledge gained at two recent international software
development and quality improvement workshops sponsored
by Japan's MITI....support this position.
At each of these meetings....there was considerable
interactive discussion and intellectual probing....many
of our team members were invited into Japanese
development laboratories and observed their latest
software code creation and process techniques......
...Please plan to attend if humanly possible.
About 60 individuals responded to this invitation, representing
research, corporate, government, and academic institutions.
The meeting, held at the University of Maryland, was poorly organized
and run, with some rough spots between the organizers and the
participants (the state of software development in Japan seemed to be
bigger news to the meeting organizers than to most of the
participants). This had the effect of making more striking the
consensus amongst the participants.
4 ATTENDEES AND SPEAKERS
The speakers were:
o Colonel Will Stackhouse, USAF
o Frank McGarry, NASA/GSFC
o Les Belady, MCC
o Tom Veliz, CTA
o Walter Scacchi, USC
o Nick Copping, Atherton Technologies
o Robert Yacobellis, Motorola
o Michael Cusumano, MIT Sloan School
o Bill Agresti, Mitre
o Brad Cox, Stepstone
Report -- USAF Japan Software Meeting 6/26/90 Page 5
ATTENDEES AND SPEAKERS
Many of these speakers (including Belady, Yacobellis, Cusumano, and
Copping) have had years of experience interacting with and working
with Japanese software developers, observing the Japanese practices
and progress, and visiting at Japanese software producers; these
aren't newcomers excited by new discoveries.
Time and space don't permit all 60 attendees and institutions to be
listed here; some of the more notable participants included (people)
Gordon Bell, Dave Cutler, Ike Nassi, Michael Cusumano, Andrew Heller;
and (institutions) MCC, NSF, Atherton Technology, Microsoft, Lotus,
Next, Apple, Bell Labs, NIST, Sloan School MIT, EDS/GM, Hewlett
Packard, IBM, Mototola, numerous branches of the military, government
labs, government agencies, universities, and of course Digital
Equipment Corporation.
All in all, a very expensive meeting.....
5 PROBLEM STATEMENT
The United States is losing world market share in the information
processing industry, and at the same time the U.S. position in
software development is eroding.
There is a "Japanese software challenge".
The Japanese have something like a 3-to-1 cost/productivity advantage
over the United States in software development, and something like a
3-to-1 to 10-to-1 quality advantage. These figures are based on
available "apples-to-apples" comparisons.
Japanese software cost/productivity and quality are still improving
relative to the United States.
These accomplishments are being made using limited human and
technology resources.
Most Japanese software developers are either Japanese university
graduates who graduate having learned very little computer science, or
(for example) crane operators who lost their job to automation and
were moved into the software development department.
Most Japanese software developers use 1970's software development
technology, and it's common for 2 - 3 developers to share a terminal.
The Japanese began their concerted efforts towards improved software
development cost and quality at the low end of the technology scale --
repetitive, traditional data processing applications. Year by year,
they are moving their acquired expertise up the technology chain to
more sophisticated software development projects.
Report -- USAF Japan Software Meeting 6/26/90 Page 6
PROBLEM STATEMENT
This is strikingly similar to what has happened in other industries.
In addition, the Japanese approach to software development is well
suited to building standardized components in standardized
environments. The continuing viability of some proprietary
environments in the United States, coupled with all the confusion in
standards (MS-DOS vs. OS-2, OSF vs. UI, MOTIF versus Sun, etc.) is
one of the forces that has prevented effective Japanese penetration of
the U.S. software market. As U.S. standards get sorted out and
standard environments become more important, the U.S. software market
will become much more vulnerable to the Japanese.
There will be few places left to hide for U.S. software producers.
Japanese software managers are quick to sieze on new opportunities and
work hard to make them succeed. When evaluating outside partnerships,
the Japanese move quickly; typically, they will make a major
investment decision within 90 days from initial contact, and will pay
within 30 days of making the decision. This is in contrast to the 18
- 24 month technology cycles of large U.S. companies.
This responsiveness is tending to drive small U.S. technology
companies in need of capital into the arms of the Japanese.
The Japanese are also aggressive at importing U.S. research; whereas
the gap between Japanese software developers and Japanese universities
is quite large, their gap with U.S. universities is small.
6 SOLUTIONS/ACTIONS
A stated goal of this meeting was to establish linkages amongst United
States software developers and enterprises, and to develop an agenda
and momentum for corrective action by the United States.
All the participants divided into five break-out groups to work on
this.
As one might expect, there was little agreement by the U.S.
participants concerning solutions, agenda, or actions. The
suggestions from the groups ranged from the impossible to the
self-serving to the merely nonsensical and frustrated.
Colonel Stackhouse is going to attempt to keep this initiative going,
possibly with followup meetings, distribution of the material, trying
to get funding from U.S. software firms for a coordinated program,
etc. He seems enthusiastic about pushing on.
My reading is that, realistically, this meeting (and any followup
participation at the next International Workshop) is all we're likely
to see out of this.
Report -- USAF Japan Software Meeting 6/26/90 Page 7
CONTRASTING THE U.S. SOFTWARE DEVELOPMENT VERSUS JAPAN
7 CONTRASTING THE U.S. SOFTWARE DEVELOPMENT VERSUS JAPAN
Some brief (perhaps overly general) introductory comparisons of the
U.S. and Japan include the following.
o The Japanese emphasize management and process; the U.S.
tends to emphasize technology (looking for the "silver
bullet" breakthrough).
o The Japanese focus on using proven technology; the U.S.
tends to focus on developing new technology. The Japanese
are typically behind the U.S. in software develoment
technology.
o The U.S. emphasizes tools and environments to equip the
transient programmer; Japan emphasizes investment in
management infrastructure and human motivation through
training and human improvement.
o The Japanese articulate well-defined measurable long-term
goals for software costs and reliability, backed up with
acievable near-term goals; in the U.S., we're unclear about
long-term goals, and measurement data is typically
unavailable to measure the benefits of new technology in the
near-term.
o Japanese software managers stay technically up-to-date, and
strive to understand software development at a detailed
technical level.
o The Japanese approach productivity and quality with a
"compete and win" mentality, rather than a "be creative"
mentality.
o Japan maintains an active, process-oriented approach to
software quality; the U.S. tends to apply a passive,
product-oriented approach.
This comparison of U.S. and Japanese software development (in this
section and elsewhere in this report) should not be taken as overly
negative about the U.S. The U.S. has many unique advantages,
including a better higher education system, national information
infrastructure, and a tradition of innovation.
However, the evidence is that Japan is out-doing the U.S. in
commercial software development. We need to learn from the
competition while captitalizing on our unique strengths.
8 DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
This section summarizes and synthesizes all the observations and
Report -- USAF Japan Software Meeting 6/26/90 Page 8
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
conclusions about the character of Japanese software development.
The best software efforts in Japan are reportedly SRA, Fuji Xerox,
NEC, and Hitachi. ICOT was emphatically listed as NOT being on the
"most effective" list. The effective Japanese efforts have strong
programs to Japanize U.S. software.
8.1 Management Of The Software Development Process
An important question is: What is there in the Japanese software
development environment (apart from cultural differences) that result
in these characteristics? Relevant attributes of the Japanese
environment include:
o Very limited engineering people resources. SIGMA estimates
that there is a one million programmer shortfall in Japan
today.
o Very high quality expectations by their customers.
o Severe competition.
That is, Japanese software development managers are faced with a
demanding environment and a scarcity of resources. Their response is
to treat software as a manufacturing business to be managed.
8.2 Use Of Simple Proven Technology
Although the Japanese pay a great deal of attention to software
development process, they are conservative in applying new technology
to software developent.
The Japanese capital infrastructure for software development is
primitive by U.S. standards.
o Typically, software developers sit in an open "bull pen"
shared by 70 - 120 people.
o Typically, 2 - 3 developers share a computer terminal.
o They have little administrative support.
o The tools and technologies they use are behind those of the
U.S. (and are characterized as "1970's software development
technology").
o There is a much wider gap in Japan between the universities
and commercial software development than in the U.S.
Report -- USAF Japan Software Meeting 6/26/90 Page 9
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
o Japanese software testing is "at a low level of automation,
but a high level of effectiveness".
o Most speakers felt that the Japanese don't get much benefit
from software re-use, and that re-use levels are comparable
to those in the U.S. (there was some disagreement about
this; Yacobellis thinks that at some companies, such as NEC,
50% of the released code is re-used).
The Japanese emphasis is on aggressively USING what's already
available to implement a well-managed, repeatable software development
process.
Doing this, they have achieved effective software process engineering
using "low technology" ("low" == "appropriate").
8.3 Productivity/Quality Goals And Improvement
Part of this Japanese orientation towards software development
includes strong, organization-wide goals for software development
productivity and quality. The organization sets meangingful long-term
goals, backed up by realistic and measurable near-term goals.
Typically, the Japanese set 3 - 5 year plans which call for 20% per
year improvement in productivity, quality, and on-schedule
performance; 12% - 25% actual improvement is the normal result.
They demand relentless, INCREMENTAL improvement (and don't expect
quantum leaps).
As a result of this approach, for example,
o Quality figures are quoted for Japanese software of 8 defects
per 1 million lines of total released software, or around 5.8
Sigma. This is recording all problems, not just
customer-reported defects.
o IBM Japan produces software which has an order of magnitude
fewer defects than that produced by IBM U.S. and IBM France.
o Hitachi has reduced software defects by an order of magnitude
in 5 years.
o With re-use, NEC developers produce about 40,000 lines of
code per year.
o The low end of Japanese software productivity is at the high
end of U.S. companies' production.
Report -- USAF Japan Software Meeting 6/26/90 Page 10
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
o 2 - 3 times improvement in productivity over 5 - 10 years has
been typical.
o IBM Japan has 2 times the software productivity of IBM
elsewhere.
o Hitachi reports a 10-fold decrease in late projects over 4
years, with evidence of a 35% - 40% shorter project cycle
time.
8.4 Productivity And Quality Metrics
The Japanese make meticulous use of metrics to assess progress towards
long-term and near-term producivity and quality goals.
o The Japanese quantify everything they can (productivity,
schedules, quality, etc.)
Tom Velez showed some charts frim Nippon Steel Information
and Communication Systems (ENICOM), showing an amazing level
of cradle-to-grave measurement built into the software
development process, including month-to-month comparative
statistics, quality and productivity metrics, etc.
o Projects are typically measured MONTHLY with quantitative
statistics, and NEW GOALS are set for the next month.
o By collecting this data, management always knows how they're
doing and how much it costs to produce software, so they can
manage it.
o These measurements give immediate feedback to the development
teams, providing continuous motivation.
o The Japanese readily admit that there is lots of "nonsense"
in their measurements (lines of code, pages of specification,
etc.), but they accept the fact of that "nonsense" and use it
to their advantage.
They don't wait for a perfect model or metrics before
exploiting these techniques.
The clear advantage for the Japanese of using these metrics is that,
whether "nonsense" or not, it provides feedback, comparisons, and as a
result MOTIVATES developers.
In contrast, there has been no clear improvement in software
production or quality in the U.S. in the last 10 years; note that
this is at least partly because there are few metrics. There may have
been improvement, but there's no clear measure of it!
Report -- USAF Japan Software Meeting 6/26/90 Page 11
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
8.5 Process Maturity
The emphasis on managing software development and use of metrics has
led to a high level of process maturity in Japan. Software
development is extremely disciplined.
o The Japanese use consistent methodology framework thoughout a
company. This leads to increased process maturity, good
metrics, and synergy across multiple software development
enterprises within a large corporation.
o The Japanese are heavy users of Humphrey's "Managing the
Software Process"; participants disagreed about how mature
Japanese software development is on Humphrey's scale, but the
estimates ranged from "shooting for Level 3 (defined process
for consistent repeatable results, and able to introduce new
technology with predictable results)" to "everything at Level
4 and Level 5 (comprehensive process management and rational
optimization of the process)".
(In contrast, only 1% of U.S. companies are believed to be
at Level 3, and 85% are believed to be at level 1 (lack of
stable process with repeatable results)).
o Possibly a sign that Level 5 is coming into place is that
fact that the defined software process in a Japanese
enterprise, while consistent at a high level of methodology
framework and metrics, is not rigid; project teams are
allowed to select and implement details of their methodology.
(Note that these are long term investments, as project teams
stay together for a long time).
Thus, there is flexibility within the larger defined process.
One quotable quote: "If you have fixed resources and fixed goals,
then the variable that you have left to control is your process".
A suggested paradigm, applied by the Japanese, is:
1. Characterize your current process and environment.
You have to write your current process down, and understand
it, before you can talk about how to improve it.
2. Set measurable goals.
3. Develop process to support those goals.
4. Execute that process and gather data.
5. Analyze and review the data.
Report -- USAF Japan Software Meeting 6/26/90 Page 12
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
6. Feedback, adjust and fine-tune process.
7. Set new goals
8.6 Company Orientation, Team Focus, And Problem Solving Orientation
These management and process aspects of Japanese software development
are backed up by supportive organizational and individual attitudes.
Japanese software development operations are characterized by a strong
company orientation and identification with the corporate mission.
o There is excellent internal communications.
o The Japanese, as individuals and as teams, maintain a
"compete and win" problem-solving mentality (rather than a
"be creative and/or perfect" mentality, or "doing something
interesting and challenging", or "practicing my profession",
or etc.).
o Japanese teams are kept together for long periods, during
which they work on a series of projects.
o Japanese software managers are quick to sieze on new
opportunities and work hard to make them succeed. The
Japanese are aggressive about exploiting outside
partnerships, rather than building in house, when this is to
their advantage.
When evaluating outside partnerships, the Japanese typically
will make a major investment decision within 90 days from
initial contact, and will pay within 30 days of making the
decision.
The essence of these attitiudes are that the Japanese are
goal-oriented for the organization, with little concern for optimizing
for the individual.
8.7 Reward Systems And Competition
The reward system in Japanese software development enterprises
reinforces all the above.
There is intense competition between Japanese software development
teams, but the competition (and the reward system) is based on
measured productivity, quality, and progress.
Report -- USAF Japan Software Meeting 6/26/90 Page 13
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
There is little competition over charter and turf....
8.8 Training And Human Improvement
Investment in people, rather than equipment and technology, is
fundamental the the Japanese approach. The priority of training is
very high. This is a response to lack of people resources, and is
made possible by a stable organizational context and a long-term view.
o The Japanese maintain a separation of "Software Engineers"
(designers) and "Software Implementors" (coders).
o The Japanese do not have a large available pool of software
engineering talent.
The universities do a poor job of producing quality software
engineers; in addition, a large part of the Japanese software
development labor pool comes from (for example) crane
operators who lose their job to automation and are re-trained
as "software implementors", or who move to software
development from other technical fields (such as astronomy
and veterinary science), and are re-trained as "software
engineers".
As a result, nearly all software development training is done
by Japanese companies, and they invest very heavily in it.
o Simple tools, keeping teams together, and the discipline of
consistent methodologies across the organization enable
displaced crane operators to become productive software
developers.
o One speaker commented that "The U.S. emphasizes tools and
environments to equip the transient programmer; Japan
emphasizes investment in management infrastructure and human
motivation through training and human improvement".
All of this is, of course, made possible by the longevity of the
Japanese workforce.
8.9 Quality And Productivity Improvement From The CEO Down
Software quality and improvement are key company objectives in Japan.
Senior management, from the CEO down, takes this seriously.
It is this management commitment to quality and producivity that
supports other elements of the Japanese software development
environment such as consistent use of metrics, long-term investment,
and incremental year-to-year improvement.
Report -- USAF Japan Software Meeting 6/26/90 Page 14
DETAILED CHARACTERIZATIONS OF JAPANESE SOFTWARE DEVELOPMENT
The focus is on a process approach to quality, NOT an inspection
approach.
As a result of this, the quality of delivered software (the reported
error rate) is significantly better in Japan than in the U.S.
Distribution:
TO: FRANK BIRCH@TRC
TO: MARILYN EHRHARDT@LAC
TO: GEORGE CHUNG@HGO
TO: STEPHEN HAIRS@SNO
TO: MIKIO SUZUKI@TKO
TO: KEITH ANDERSON@SNO
TO: JOHN GARLICK@KAO
TO: RICHARD RYDBERG@MEO
TO: JEFF WILKINSON@NZO
TO: EDDIE LUI@HGO
TO: SHOJI ITAGAKI@JSO
TO: MASAHIRO YAMADA@TKO
|
| 1225.13 | IBM and quality: long info in next reply | BIGUN::ANDERSON | The Unbearable Lightness of Being | Wed Oct 17 1990 07:45 | 0 |
| 1225.14 | Quality at IBM (long reply) | BIGUN::ANDERSON | The Unbearable Lightness of Being | Wed Oct 17 1990 07:51 | 564 |
|
Tel No: (02) 412 5666
TO: See Below
Subject: FYI* QUALITY AT IBM
For your info.
Regards,
Jan
Attach.
d i g i t a l
I N T E R O F F I C E M E M O R A N D U M
Date: 17-Jan-1989 05:49 AED
From: Edward Bishop @DAS
( BISHOP.EDWARD AT A1 AT FSLMTS AT DAS
Dept: FSL Materials
Tel No: 275-2305
To: See Below
Subject: QUALITY AT IBM
THE FOLLOWING IS A REPORT ON THE QUALITY PROGRAM INSTITUTED ACROSS IBM AND
SPECIFICALLY IBM CANADA($2.5B BUSINESS).
I N T E R O F F I C E M E M O R A N D U M
Date: 14-Jan-1989 09:42am EST
From: Paul Mantos
MANTOS.PAUL AT A1 at OURVAX
at MRO
Dept: U.S. - MFG. EXCELLENCE
Tel No: 296-3787
TO: See Below
Subject: IBM IS AFRAID OF JAPANESE COMPETITORS - WHY NOT DEC??????
From: NAME: John Morris
FUNC: Field Service Marketing
TEL: DTN 631-7142 <MORRIS.JOHN AT A1 at TRCO01 at TRC>
Please find attached a summary of an address given by an IBM staffer on the
subject of quality and customer satisfaction.
Best Regards,
John Morris
Research and Information
FS Marketing
Digital Canada
QUALITY AT IBM CANADA
Trip Report on Address
by Robert Beggs, Director, Quality
IBM Canada Ltd.
December 13, 1988
Toronto
Sponsored by
Industrial Marketing and Research
Association of Canada
Report by John Morris
Research and Information
Field Service Marketing
Internal Use Only
--------------------------------------------------------------------------
Robert Beggs, a 30 year IBM veteran, has been IBM Canada's Director of
Quality for the last six years. His talk on December 13th focused on the
evolution of the quality concept at IBM. Beggs covered the IBM quality
program from its initiation in manufacturing to its current role in
enhancing customer satisfaction. Beggs reports directly to IBM Canada's
Chairman -- an interesting measure of the importance IBM attaches to its
quality programs.
This summary records Beggs' remarks made during his 1.5 hour address. As
Beggs' comments were well organised, they are presented in the same order
as his talk. Beggs' remarks are also reported at face value and no attempt
has been made to judge the IBM's actual success in quality.
Readers outside Canada may be interested to know that IBM Canada Ltd.
generates about $2.5 billion U.S. annually in revenue, of which about 30%
is accounted for by exports. IBM Canada employs about 12,000 people.
-------------------------------------------------------------------------
CONTENTS
History of Quality at IBM
The Context Within Which Quality was Implemented at IBM
Competitive Pressure the Original Stimulus to IBM's Quality
Programs
The IBM View: Quality Delivers and Quality is Simple
Quality at IBM in 1982
Quality at IBM in 1987
Characteristics of Quality at IBM
The Len Barry/Texas A&M Model of Customer Satisfaction
Customer Satisfaction the Apex of IBM's Quality Program
Questions from the Audience
HISTORY OF QUALITY AT IBM
IBM has been explicitly promoting quality now for 10 years. During that
period of time, the focus of quality improvement has changed as shown in
the following chart:
FOCUS: Product People Process Customer
Reliability Participation and Performance Service
Internal Focus ---------> External Focus
YEAR: 79 80 81 82 83 84 85 86 87 88 89 90
During the past 10 years, the IBM quality focus has shifted from an
internal focus to an external, customer focus. Beggs states that this
shift reflects only the increasing acceptance of quality within IBM and NOT
necessarily the best method of quality implementation.
THE CONTEXT WITHIN WHICH
QUALITY WAS IMPLEMENTED AT IBM
IBM's quality program built upon IBM's core values of
1. respect for the individual
2. the best in customer service
3. excellence in everything they do
and IBM's stated mission,
1. customer partnership
2. leadership in products and services
3. growth with the industry
4. operational efficiency
5. sustained profitability
Beggs feels that programs, of which the Quality program is an example, will
only succeed if they are compatible with an organisation's underlying
culture.
COMPETITIVE PRESSURE THE ORIGINAL
STIMULUS TO IBM's QUALITY PROGRAMS
By the late 1970's, IBM's senior management had become increasingly
concerned about Japanese competition. This concern was heightened by the
knowledge that during the 70's several American computer firms had already
closed shop.
It was at this point that IBM discovered two things: (1) in many areas,
they could improve the way they did business and (2) their business
improvements generally did NOT require "rocket science" for success.
Working with quality guru Crosby, IBM chose the quality paradigm as the
vehicle for business improvements.
Two years after the initial implementation of the first IBM quality
circles, the quality program had spread to most IBM manufacturing
facilities throughout the world. It then became apparent that quality
would probably be useful throughout all business functions. This was
achieved by 1982.
Throughout this period, IBM management were motivated by the knowledge that
"either IBM delivers defect-free goods and services to their customers, OR
SOMEONE ELSE WILL". IBM takes the position that quality of service is key
to customer satisfaction. In turn, customer satisfaction is key to
competitive advantage.
Critical for the success of the IBM quality program was the "decision
making template" within which the quality program was run. The quality
program mission was endorsed within IBM at the highest levels. Quality
goals were made explicit, long-term and organisation transcendent. Quality
itself was made an integral part of IBM strategies and IBM team efforts.
THE IBM VIEW:
QUALITY DELIVERS AND QUALITY IS SIMPLE
Throughout his talk, Beggs made reiterated one point over and over again.
Quality is not just pie in the sky, but delivers four key inter-related
benefits:
1. Quality drives market share through product acceptance.
2. Quality contributes positively to both revenue and costs.
3. Quality appeals to pride of craftsmanship by IBM employees.
4. Quality is a critical component of IBM's reputation.
BUT NOTHING IN THE QUALITY PROGRAM IS COMPLICATED OR DIFFICULT -- WHAT IBM
HAD ACHIEVED BY 1985 IN QUALITY COULD EASILY HAVE BEEN ACHIEVED IN 1970!
It was competitive pressure by Japanese firms that forced IBM to confront
the accepted, to pursue excellence where previously an 'ok' would have been
acceptable.
QUALITY AT IBM IN 1982
By 1982, IBM's quality game plan included
1. definition of quality goals and strategy
2. a commitment to train management personnel first in quality
3. a commitment to integrate quality improvement processes into the
management system
4. an inclusion of quality goals as part of performance plans.
IBM's 1982 quality related goals were "modest":
1. Improve customer satisfaction
2. Improve employee morale
3. Improve all business processes
QUALITY AT IBM IN 1987
By 1984 and 1985 though, IBM faced several new challenges: one of the most
important of which was handling the enormous increases in transaction
volume generated by their success in the PC market place. Other challenges
included
1. IBM's growing suite of products.
2. IBM's increasingly strained business processes.
3. More frequent customer problem escalations.
4. More frequent IBM business unit audit failures
5. Increasing concern about IBM's ability to meet its business goals.
Beggs pointed out that in order to meet IBM's ambitious business goals, IBM
would have to process a number of transactions in geometric proportion to
its increase in revenue! This increase in process throughput required
improvements in process efficiency in orders of magnitude.
Process issues related to this problem were identified as follows:
1. IBM managers sometimes lacked understanding of how business processes
functioned.
2. Process documentation was often either out of date, too low level or
even non-existent.
3. Process changes were difficult to accommodate.
4. IBM's image was suffering due to process problems.
5. There was a significant upside to process improvements.
During this period, IBM focused considerable resources on improving process
quality. Having achieved relative success in this effort, IBM was now free
to enter a new phase of its quality program. This new quality orientation
arose in response to IBM's new understanding of its competitive position:
FACT: This is a service economy
FOCUS: Business is about relationships, not physical products
OPPORTUNITY: Providing value added services
COMPETITIVE ADVANTAGE: Service quality. Organisations offering quality
service seem to make it easy for their customers to do business with them.
And anytime an exception to a normal transaction occurs, organisations
offering quality service respond immediately and massively.
By 1987, Beggs now had a full time staff of 12 and several years experience
under his belt. He was one of fifty staff in similar positions around the
world in IBM. Along with IBM units world-wide, IBM Canada restated its
quality strategy as:
1. Include the customer viewpoint in everything. IBM's first foray into
quality (in manufacturing) had not explicitly included the customer
viewpoint.
2. Define IBM's key principle as "doing the right thing -- right the first
time".
3. Including quality in the management system.
4. Enhance the problem solving techniques repertoire of non-management
personnel. (It had been learned that quality worked best when typical
management problem solving techniques were applied to a situation.
However, it had previously been taken for granted that all employees were
aware of these techniques. Non-management personnel benefited from basic
training in problem solving techniques and thereby become more effective as
implementers of quality.)
5. Recognise achievement -- in non-monetary ways. Such recognition is in
addition to the well known IBM program of payment for successful
suggestions. Recognition of achievement is key for building participation
in quality programs.
6. Share quality implementation success stories.
CHARACTERISTICS
OF QUALITY AT IBM
IBM had first been introduced to quality by Vice President Phil Rizzo, who
happened to be a golfing partner of Phil Crosby. At that time, Crosby was
known for his quality programs at ITT. Crosby's approach remains the
centre of the IBM quality program although IBM also incorporates elements
from Demming, Juran and Fegenbaum.
Quality at IBM is defined as conformance to customer requirements.
IBM's quality goal is to be defect free.
IBM's quality methodology is prevention.
IBM's quality measurement is defect tracking.
IBM has taken some trouble to understand what characterises a service
product. Following on the work of Jan Carlson, IBM sees service as
"perishable, comprised of unique performances, being consumed and produced
at the same time ...etc."
Of course IBM is aware of the cost of service and is not interested in
expending more resources than necessary to achieve customer satisfaction.
The balance of service cost and customer satisfaction is summarised in
IBM's customer satisfaction hypothesis:
Perceived Service
Customer Satisfaction = --------------------
Expected Service
In other words, one can enjoy a MacDonald's hamburger because it was what
was expected and still be dissatisfied with a meal at Winston's because it
fell below expectations. (Note to readers not from Toronto: Winston's is
one of Toronto's most expensive restaurants.)
IBM has also used the work of Len Barry et. al. of Texas A&M University.
Barry conducted research for the American Marketing Association asking the
question: "Is there anything common about service quality across different
industries". Barry answered YES as follows:
ABSOLUTES OF SERVICE QUALITY
1. Reliability -- you did what you said you would
2. Responsiveness -- you were willing to help when things didn't go as
planned
3. Empathy -- your employees were courteous and knowledgeable and were able
to convey trust and confidence
4. Assurance -- your customers received "caring, individualised attention"
5. Tangibles -- your customers liked what they could actually see
Barry developed an interesting model of customer satisfaction. The model
is outlined below.
In Barry's customer satisfaction model, the boxes are steps in the customer
satisfaction process. The most interesting feature of the model, is the
identification of five critical "customer satisfaction gaps".
THE LEN BARRY / TEXAS A&M
MODEL OF CUSTOMER SATISFACTION
AS PRESENTED BY IBM
Word Perceived Past Competitive
of Mouth Needs Experience Communications
| | | |
| ---V--------------------V----------- |
---------->| |<---------
| CUSTOMER EXPECTATIONS |
-------<| |<--------|
| ------------------------------------ |
| ^ |
| | |
--- --- |
GAP GAP |
ONE FIVE |
--- --- |
| | |
| ------------------------------------ |
| | CUSTOMER PERCEPTIONS |<--------|
| ------------------------------------ |
| ^ |
| | | LINE OF
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | VISIBILITY
| ----------------------------------- |
| | SERVICE EXECUTION |<---------|
| ----------------------------------- |
| ^ |
| | |
| --- |
| GAP |
| THREE |
| --- |
| | ^
| ----------------------------- ------------------
| | TRANSLATION | | GAP| | EXTERNAL |
| | OF MGMT PERCEPTIONS |<-|FOUR|->| COMMUNICATIONS |
| | TO SERVICE SPECIFICATIONS | | TO CUSTOMERS |
| ----------------------------- ------------------
| ^
| |
| ---
| GAP
| TWO
| ---
| |
| ----------------------------------
| | MANAGEMENT PERCEPTION OF |
|------>| CUSTOMER EXPECTATIONS |
----------------------------------
According to Barry's work, gaps in the customer satisfaction process can
only be closed successively. In other words, Gap 5 can only be closed when
Gap 4 is closed, which in turn can only be closed if Gap 3 is closed etc.
The first gap that must be closed is that between what management believes
customers want and what customers actually want.
IBM uses various management programs and tools to close each of the above
gaps. IBM believes that while these gaps will always exist in greater or
lessor degree, IBM will be successful if they are better than their
competitors at closing these gaps.
Begg's only had time to discuss Gap No. 1 in detail, the gap between
management perception and customer needs. Begg's identified five reasons
for the existence of this gap:
1. Insufficient market research.
2. Inadequate use of market research.
3. Lack of contact and interaction between management and customers.
4. Insufficient communication between front-line, customer contact
employees and senior management.
5. Too many layers between front-line, customer contact employees and top
management.
It is easy to see that Reason No. 5 above would be particularly important
to IBM, given IBM's more hierarchical organisation structure.
In the context of discussion around Gap No. 1, Beggs made the interesting
comment that research literature shows an ALMOST PERFECT CORRELATION
BETWEEN WHAT FRONT-LINE PERSONNEL THINK AND WHAT CUSTOMERS THINK. In other
words, surveys of internal front-line staff is valid method for obtaining
information on customer satisfaction.
CUSTOMER SATISFACTION THE
APEX OF THE IBM QUALITY PROGRAM
IBM draws several conclusions from the application of the Barry model:
1. Manage consistent customer communications. Measure customer
perceptions.
2. Put strong emphasis on customer and front-line personnel.
3. Make every customer contact support the goal of maintaining an ongoing
buying relationship.
4. Implement support tools that enhance service quality.
Beggs elaborated on point number two, quoting Barry that "service
excellence is possible only when individual employees have great pride in
their company." And Beggs went on to state that for employee pride you
need:
1. Superb product quality
2. Meaningful employee participation
3. Hassle free business processes
QUESTIONS FROM AUDIENCE:
IF QUALITY IS SO SIMPLE,
WHY IS IT ALSO DIFFICULT?
1. Given that Beggs' strongly emphasised the common-sense nature of
quality, I asked why it took Japanese competitive pressure to make North
American corporations see the light.
Beggs responded with a "sociological" explanation, giving his view that
North American managers are predisposed to "crave complexity". A "common
sense" and "down to earth" focus on the details of quality isn't always
"sexy" enough for high-powered managers. Further, some management
practices are at odds with a quality focus. Beggs gave the example of
"delegation" as a management practice usually thought of as the mark of a
good manager. While this is true he said, delegation can also interfere
with a manager's involvement with important but routine quality issues.
HOW IS QUALITY IMPLEMENTED
IN STAFF FUNCTIONS AT IBM?
2. I asked about the applicability of quality tools designed for volume
manufacturing process to discontinuous work environments typical of staff
functions.
Beggs stated that IBM used a variety of tools in all quality processes,
included Pareto analysis, Ishikawa diagrams, brainstorming etc. IBM found
that quality circles did not work in professional environments. As a
result, quality in such staff functions is handled on a project basis like
any other task.
Date: 10-May-1990 09:31 AES
From: Ian Pugsley
PUGSLEY IAN
Dept: SPR Software Licensing
Tel No: [61]-(3)-8959208
TO: See Below
Subject: IBM's quality commitment
You may be interested to read the first news item (right after their
financial statement) in IBM's quarterly report (the March 1990 quarter):
First Quarter News Review
A renewed commitment to quality
Quality topped the agenda at a meeting this January of IBM's senior
executives from around the world. During the course of the meeting,
company management launched a comprehensive program designed to
virtually elimionate defects from every IBM solution and business
process. The overall framework for addressing the company's objective
is market-driven quality, a concept which extends IBM's quality focus
beyond product reliability to every aspect of the company's
relationship with its customers.
"Market-driven quality means understanding quality as our customers
see it," said IBM Chairman John F. Akers. "Our aim is to make every
IBM offering and every contact with our company perfect in the eyes of
our customers."
To this end, the company is establishing measurements that reflect the
views of the marketplace on IBM's offerings and services. These
measurements will allow the company to better direct the efforts of
its employees, vendors and Business Partners to deliver world-class
solutions.
Distribution:
TO: Rob Benco ( BENCO ROBERT@A1@MEO78B@MEO )
TO: Tony Bonanno ( BONANNO TONY@A1@MEO78B@MEO )
TO: Mark Cleary ( CLEARY MARK@A1@SNOC02 )
TO: Carol Clough ( CLOUGH CAROL@A1@MEO78B@MEO )
TO: Peter England ( ENGLAND PETER@A1@MEO78B@MEO )
TO: Lawrie Hanson ( HANSON LAWRIE@A1@MEO78B@MEO )
TO: Timothy Hughes ( HUGHES TIM@A1@MEO78B@MEO )
TO: Jim McNally ( MCNALLY JIM@A1@MEO78B@MEO )
TO: Sarah Rankin ( RANKIN SARAH@A1@MEO78B@MEO )
TO: Richard Rydberg ( RYDBERG RICHARD@A1@MEO78B@MEO )
TO: Richard Sherratt ( SHERRATT RICHARD@A1@MEO78B@MEO )
TO: Andrew Turnbull ( TURNBULL ANDREW@A1@MEO78B@MEO )
TO: John Cummings ( CUMMINGS JOHN@A1@MEO78B@MEO )
TO: Neil Bannister ( BANNISTER NEIL@A1@MEO78B@MEO )
TO: Eve Kleiman ( KLEIMAN EVE@A1@MEO78B@MEO )
TO: Brian Smallman ( SMALLMAN BRIAN@A1@MEO78B@MEO )
TO: Kim Liesching ( LIESCHING KIM@A1@MEO78B@MEO )
TO: Nigel Page ( PAGE NIGEL@A1@MEO78B@MEO )
CC: Frank Wroe ( WROE FRANK@A1@SNOC02 )
CC: Rustom Kanga ( RUSTOM KANGA @SNO )
CC: Murray W. Ray ( RAY MURRAY )
CC: Jane Thornton ( JANE THORNTON @SNO )
|
| 1225.15 | *********** | NBOIS3::BLUNK | Bruce P. Blunk NBO | Wed Oct 17 1990 09:11 | 41 |
| Alan,
I do not want to get into a philosophical debate about slogans, and
coporate goals, vision etc. Note 0 and several comments refer to
Quality as a goal and indeed company philosophy and thought this 1987
poster has something to say about what Quality should be for DEC.
I have had contact with Digital since the late 60's as student,
customer, and now employee. I do feel that in the past Digital has
tried to provide quality for its customers, and believe that it is
still a basic goal (philosophy). Certainly all forms of advertisement
contain slogans, but I think this poster is trying to convey something
more. I work in the IS department at the Nuermberg Germany office so
our customers are the computer users here and at remote locations which
we service. Our goal really is to provide the best quality service
possible..... we try to do the best we can with the resources we have
at our disposal. We believe Quality Service is one of our basic goals.
Question 1 is not easy to answer. I think the basic "Vision" for
Digital has always been to be a Great Computer company for its
Customers and EMPLOYEES. Just about 5 years ago I started working
for DEC here in Germany and I felt an atmosphere of excitement and I
was really motivated..... Now it seems the excitement is almost gone
and I am often demotivated (although not demoralized). Most of the
problems occuring in the U.S. are happening here in Germany (Europe)
so this does seem to be a Digital International Problem. By the way
I am an American living in Germany for several years so know both
worlds rather well.
Perhaps the most important statement in the above said poster is
"Quality begins with management leadership. Is our management now
content with good (or mediocre) instead of great (excellence)? I
don't know.
History shows that only visionary leadership can inspire and ultimately
bring (people, organizations, nations) through difficult times.
Lincoln's vision of a United America brought the nation through a
terrible civil war and ultimately the union of all states.
Luther brought about the reform of Church and State in Germany.
This is the kind of leadership we need....... Now to keep a vision
alive.
|
| 1225.16 | market no place for de-bugging | HEFTY::CHARBONND | DELETE the Simpsons | Wed Oct 17 1990 10:01 | 10 |
| Sounds like we've confused very technologically advanced products
with *good* products. I don't believe any amount of technological
'leap-frogging' of our competitors' products will make up for a
reputation for poor quality. (Even the Soviets know this - their
rockets aren't as fancy as the Space Shuttle, but they get their
payloads up on time.)
Put another way, as customer, do you want 'state-of-the-art' or
will your business needs be better served by 'bugs-already-
worked-out' ?
|
| 1225.17 | Did we ever have quality? | RANGER::JCAMPBELL | | Wed Oct 17 1990 18:45 | 70 |
| re: .15
I think Alan is correct in questioning whether Digital ever had
the kind of commitment to quality which was advertised in the poster.
I believe that our commitment to quality was superficial, at best.
If the engineers in a group were willing to apply (ancient technology)
code reviews to the code, then it turned out better. For those
groups that never reviewed each other's code, the quality was awful,
and continues to be awful. Our hardware groups are the same way: the
quality is spotty. Where Deming/Taguchi techniques have been applied,
it is better. Where they haven't, is isn't.
I'm reminded of a giant (15' x 30')
billboard in Lynn, Massachusetts at the GE plant: "Where Zero Defects
Is A Way of Life" (This was in 1971). Same superficial (media hype)
slogan. Little implementation.
(and re: .16)
Our definition of quality has not changed with market conditions.
Nor has our commitment to it. The world is changing around us, and
customers are not going to put up with spotty quality any more. They'll
buy from us when they must make a choice about price/performance and
we happen to have the slightly cheaper/slightly faster machine.
But those kind of decisions make less sense in a declining or
flat market, when managers cannot make risky decisions. They will
become more conservative, and want hardware and software that will
stay up forever, not need any special care and feeding, and run
everything flawlessly. AND FUJITSU (or pick your favorite high-quality
competitor) WILL BE THERE. (Fujitsu is now the second largest vendor
of software, behind IBM).
If you want a measure of software quality, ask ANY VMS ENGINEER how
much of new VMS code is code-reviewed or inspected. Then ask ANY
LANGUAGE ENGINEER the same question. And then ask the most telling
question: ask the same people how many engineers in these same groups
have analyzed CSC/SPR data to find out where the defects have come
from. I believe you'll get an answer that is very close to ZERO
in all cases.
Instead of striving for zero defects, we strive for
zero contact between the customers and our engineers, creating more
and more levels between them. (VMS, I think, tops the ratings in
this endeavor. They have the CSC screening problems AND a separate
maintenance organization, in addition to the development engineers.
The only problems that ever bubble up to the developers are
incredibly critical ones involving abstruse areas of VMS that,
if broken, could cause major lawsuits, embarrassment to Digital,
or immediate loss of a major customer. The developers haven't a CLUE
to what sections of VMS cause the most problems in the field, or what
design decisions they have made affect the quality of the product.)
Furthermore, we make product requirements/design decisions in such
an ad hoc (or add hack) way that it is surprising that we ever
meet the needs of the customer. Scientific analyses of customer
requirements (such as QFD) are extremely rare.
All of this has to do with ego, of course. The Japanese have mastered
the methodology for ego-less development of hardware and software. They
don't feel personally affronted if a customer thinks what they produce
is junk. They listen carefully and fix the process that produced the
defect that caused that customer to think it was junk. We agonize
over whether the customer is a jerk or whether the developer
is a jerk. (Either or both may be true, BUT IT'S NOT IMPORTANT!!!).
Let's hope the upper management reads these notes and heeds our
advice; if they don't, it is to OUR peril...
Regards
Jon
|
| 1225.18 | Individual Choice or Mgt. Mandate? | CURIE::DIMAN | | Thu Oct 18 1990 12:44 | 28 |
| Many moons ago when I first joined this company, I was told that
we built better products than IBM because we really listened to
our customers. I was told that the one of the major and most
successfull forums for getting first hand customer feedback was
DECUS. DECUS was run by customers who organized the agenda,
set up interest groups and ultimately told Digital what their
needs were. Not like IBM's SHARE user group which was simply
a forum for IBM to convey its plans and messages. But things evolved
and many of us failed to perceive that the DECUS member who we
classified as "user" was not necessarily the end of user of the
computer system - but rather an implementer, solution developer,
or system manager. What this individual defined as quality or
functionality was not necessarily what the other users wanted to
or expected...
The bottom line is that the DECUS mentality still lingers on and
and our all our development groups haven't implemented 1990's
methodologies - like QFD - to get the right kind of customer/user
involvement in helping us build the quality products that they want.
In Japan, developers can spend as much as 40 days on QFD at the
start of a project. I heard of an instance here where some engineers
said they didn't have time to even attend a one-day QFD seminar!
Do we implement 1990 development methodologies because they are the
right thing to do? Or do we have to wait for management to
reorganize and mandate change?
|
| 1225.19 | Anonymous reply on management measurement | RANGER::JCAMPBELL | | Thu Oct 18 1990 14:39 | 58 |
| Someone from MLO asked me to post this anonymously. I received it this
morning (18-Oct-1990).
To: RANGER::JCAMPBELL
Subj: Quality and measurement
I just read your message to Jack Smith and wanted to compliment you on
your insight.
Of course, I disagree with there being no measure for managers - out
here managers seem to be measured on their ability to make the next level
of management feel good. Those who raise issues and make the next level
worry quickly become outcasts, not fit for raises or promotion.
I think this method of measure is may also be used in the engineering
group we deal with in the Mill, judging by the products we get out here.
Remember, all of those defects sent to the customer aren't manufacturing
defects -some are "known bugs in the CPU chip," "known bugs in the microcode,"
and "know bugs in the software." But thats allright - ship it!
You and I know you can't test in MTBF, it has to be in the design to start
with and then not diminished by the process. But the lack of accountability
for the field performance of a design, by the design engineer causes to many
of them to shrug off responsibility, please their boss by calling it complete,
and going on to the next project.
Somehow the company needs to change the great god On_time_and_under_budget to
The_customers_loved_it.
There needs to be a change in attitude from valuing an extremely complex design
to valuing one that is easy and inexpensive to manufacture and that most of all,
meets the customers needs. Complex custom chip designs and HDA's with 76 parts
don't do that as well as off the shelf chips and simpler mechanical designs do.
I remember doing a competitive analysis on the PC AT a few years back, right
there in LJ02. One of the people with me remarked, "How dare they call this
Advanced Technology." It was all off the shelf components, but you know, when
we got thru tearing it apart, it went together in a minute and a half flat! Try
that with any of the PCs we offered. Yes, we had lovely, elegant custom chips
an elegant proprietary bus, and our own operating system on the Pro, but it cost
an arm and a leg to build it, put it together and test it. And other peoples
applications didn't run under POS, it cost too much, and the customers didn't
want it.
Marketing needs to be done before the design, not after the thing is built. The
Company needs to sell more - software and hardware - but I'd hate to be asked
to sell something that was designed to please an engineer's ambition or fancy,
rather than a customer's need.
I thought for a bit that Six Sigma was going to be taken seriously, and we could
pull off a turnaround in Quality like Motorola did, but I'm seeing it being
treated as just another "buzz word" like Design for Testibility and Design for
Manufacturability and Total Quality Control, etc. As I've remarked a number of
times lately, there are more people here interested in building their careers
than interested in building computers and so we all may lose.
If you forward this, please delete the header, and just sign me
"Trying to integrate options that don't work like they are supposed to, into
systems that don't work like they are supposed to."
|
| 1225.20 | Reply to .17 | TLE::MINAR::BISHOP | | Thu Oct 18 1990 14:48 | 17 |
| re .17, "Ask any languages engineer"
I'm a languages engineer. On one of the projects I've been on,
we _did_ do code reviews and inspections. After some time doing
them, I (at least) came to the conclusion that they didn't help
enough to be worth the time invested. Design inspections, on the
other hand, are valuable.
On the other hand, all the projects I've been on--and the
other projects in the group I'm in--are very concerned with
maintaining quality, being responsible to our customers, and
extracting information from the SPRs and QARs etc. we get.
Several people in my group argued long and forcefully _against_
having the Colorado SPR screening at all--we wanted to get ALL
the SPRs: duplicates, dumb questions and all. We lost that
argument.
-John Bishop
|
| 1225.21 | Our engineers are the best, but... | RANGER::JCAMPBELL | | Thu Oct 18 1990 17:51 | 26 |
| I did say "close to zero", not zero. Obviously you and your co-workers
had a commitment to quality which I think you probably realize is
unusual. This is not to say that the *engineers* don't care - in most
cases they truly want to produce quality code that is bug-free - but
are under such pressure to get the product out that paying attention
to quality issues is nearly impossible. In many organizations an
engineer cannot safely propose taking extra time - either up-front or for
testing - that would cause a "schedule slip."
I have heard this sad story from several language engineers (many of
my Digital friends are in TLE) and I believe it is endemic to the
entire Corporation. It is certainly my own experience since I began
working on VMS-related software five years ago.
I do NOT want to denigrate the efforts of our engineers - who I
consider some of the best in the world. It is to make constructive
criticism of the *management* of those engineers - that because we
are not allowed to measure the quality of the work that we do,
because we do not feel empowered to make changes, and because our
management does not value quality as it should, that our morale
has deteriorated to the point where we get caught up in the same
mentality. (How often have you heard someone, in jest, say "It
compiles; let's ship it!").
Thanks
Jon
|
| 1225.22 | The VMS support/Maintainence group | STAR::PARKE | I'm a surgeon, NOT Jack the Ripper | Thu Oct 18 1990 18:53 | 31 |
| Re .17:
Jon,
The support group was NOT created to insulate the engineers. In fact
it was created to be the first line of RESPONSE to the customers. This
group sits next to the CSSE VMS Support group which means they now can
walk 2-3 offices to get engineering support for a real or perceived
problem (CLD, SPR or QAR) from a customer.
Most in the group are expert in VMS, and in more than one area of VMS.
But the group also has the charter to provide immediate engineering
respond to external stimuli, and do not have project (next whenever
version feature) responsibilities. This also benefits VMS in general
as they hear from unhappy customers. Educated feedback into the VMS
system from the customers is invaluable in determining where there
are weak areas in the system (which can be old bugs or just the
design center shift from a uniprocessor 780 to a cluster of 16 9000s).
This group can also provide this.
Sure, future quality and all of these wonderful techniques is
commendable, but we must also deal with those products which are
already out there, and previous versions of products also.
I wouldn't be at all surprised if an fast engineering response
capability would be a benefit to other product areas. For instance,
there is also a DECnet "maintenance" group for similar reasons.
By the way, I am a member of BOTH VMS Development Engineering
and the VMS Support ("maintenance") group.
Bill
|
| 1225.23 | | ROYALT::KOVNER | Everything you know is wrong! | Thu Oct 18 1990 23:41 | 39 |
| I have to reply to .19 in which is said:
> But the lack of accountability
> for the field performance of a design, by the design engineer causes to many
> of them to shrug off responsibility, please their boss by calling it complete,
> and going on to the next project.
As an engineer, I object to the implication that engineers just call a
project complete so they can move on to the next project. I felt that a
project that I worked on was incomplete, as did other engineers, but we
shipped anyway, because some levels of management wanted the revenues
in a particular quarter. Two weeks later, we had the fix for the two
major bugs, and a ROM upgrade was shipped to the customers that
complained. (This was not as bad as it sounds. Those customers who used
VMS only would have no problems. Those customers that used Ulrix or
Unix could find their units unusable until the upgrade arrived.)
The engineers, however, did NOT feel the project was complete.
> Somehow the company needs to change the great god On_time_and_under_budget to
> The_customers_loved_it.
I agree 100%. Add "we need the profit in this quarter..."
Now, let me add that all the levels of my management that I've met are
better than this might lead you to believe. They are saying the right
things, and seem to be doing them, as far as they are allowed. (I know
some will argue that they should do the right thing anyway; but this can
be hard to do when you don't have the money to pay the people to do
it. Midnight projects only work if there is a project to support the
engieers, with enough slack for them to have the time.)
I now hear managers saying the right things, and I'm willing to give
thim time to see what they have learned, and what their managers have
learned.
|
| 1225.24 | You misunderstand, I think... | RANGER::JCAMPBELL | | Fri Oct 19 1990 01:24 | 63 |
| re: .22
Bill,
I think somewhere we have a perception problem. When I hear that
VMS has a serious backlog problem, that the CSC is swamped (SPR
in the hundreds), and then I see a well-worn note about a DATA
CORRUPTION problem in the VMS cache, in which the author (I did not
save the memo) was suggesting possible strategies for finding out
why the corruption was occurring, it seems to me that there is a
serious problem with quality.
When someone develops a maintenance group for a product, one has
to ask the important question: "Why are we doing this?" The message
I heard when the group was formed (again, in a memo that I did not
keep) was *specifically* to insulate the VMS development engineers
from the day-to-day problems - so that they could concentrate on
what-was-to-be V6 (can't remember its code-name). This is NOT to say
that such a move is ALWAYS a bad thing; look at what the IBM folks
did who isolated themselves and came up with the PC. And it is true
that when you have a product that is as complex as VMS and as complex
to use and configure as VMS you need some screening so that developers
don't get people calling them with SYSGEN parameter problems.
What I was specifically talking about was the analysis necessary on
the raw data to determine WHY defects occurred in VMS. When you have
two levels of support personnel between the developers and the
customers, the problems that the customers perceive do not get
to the development engineers in any clear way, and there is little
possibility that the *mechanism* for introduction of defects can ever
be established. (When I say mechanism, I'm not talking about green
engineers, but rather things like "data structure and its use too
complex for mortals to understand" or "code to perform the operation
split between many modules" or some such thing).
I am gratified to hear that some SYSGEN parameters, if I understand it
right, are going to be integrated into VMS so that they are
self-tuning. (Not that this is new technology; TOPS-10 and TOPS-20 did
that many years ago.) SYSGEN parameter tuning is one of the things that
most frustrates system managers, and it's great that the VMS engineers
heard that feedback and acted on it.
But I am mortified that we seem to be doing little (or doing something,
but too slowly) regarding the installation of software, for
instance. VMSINSTAL just does not cut it. It should be more simple,
and, of course, automated. And having to REBOOT your system just in order
to add the GBLPAGES necessary to add the command for a product to
DCLTABLES is really the last straw. How do you explain THAT to a
mechanical engineer who got his VAX workstation to do mechanical
engineering, not VMS system management.
Again, please don't get me wrong. Neither this note, nor, I think,
any of its replies, denigrates the efforts of any engineers at Digital,
except perhaps to say that after an engineer is stomped-upon enough
times for making waves, he or she becomes reticent to make waves.
That's a healthy defense mechanism, not a shirking of responsibility to
produce quality software. Pleasing the boss can become the primary
motivation, rather than pleasing the customer; uncomfortable topics,
such as low quality, are avoided. This is the indication of an
unhealthy group or an unhealthy company.
Thanks again
Jon
|
| 1225.25 | Another anonymous reply | RANGER::JCAMPBELL | | Fri Oct 19 1990 01:30 | 32 |
| Here is another anonymous posting. Since it is
second hand, I cannot, of course, verify the validity of each and every
detail. If the report is true, which I believe to be the case,
it is a stark example of wholesale internal dishonesty.
My intention here is NOT to denigrate the
efforts of the thousands of engineers, technicians, writers, and managers
who are honest and dedicated to quality workmanship. Rather it is to
illustrate the fact that the lack of commitment of the entire Corporation
to *real* quality in measurable terms, combined with our decentralization,
has led to really serious problems. These problems must be acknowledged
and addressed for Digital to become what we would all like it to be.
Jon
To: RANGER::JCAMPBELL
Subj: fyi
please do not forward with my name on it. i trust the person's account of this
i found out that in past years, DEC's customer surveys were done (at
least at one sales office) in the following manner:
1. sales and f/s people SUBMIT NAMES of customers to be polled.
2. some central org. sends out the "random" questionnaires.
3. In parallel, sales people are told by distr mgr to make sure the customer
was happy, and in one case, the sales person HELPED THE CUSTOMER FILL OUT
the form, since the distr mgr required an 8.5 (out of 10) rating or better.
4. Central office tallies and comes up with wonderful customer
satisfaction numbers.
|
| 1225.26 | .25 is not news | A1VAX::BARTH | Special K | Fri Oct 19 1990 11:18 | 17 |
| .-1 is not a big surprise.
Many offices in the field operated this way for years.
By and large this fraud has been eliminated. It has not been replaced
with a particularly valid measurement of customer satisfaction, though,
IMHO.
Like Tom Peters says, if you want people to believe you care about
customer satisfaction then you have to measure it. If you measure it
yearly, but you measure margin/revenue/etc monthly, words are not necessary.
People _know_ what is important to you.
Ask any sales DM who looks at their BOD numbers weekly and worries about
the customer satisfaction survey for a week or two every springtime.
K.
|
| 1225.27 | | RICKS::SHERMAN | ECADSR::SHERMAN 225-5487, 223-3326 | Fri Oct 19 1990 15:01 | 13 |
| The previous notes point out a flaw in measurement systems involving
skewing the randomness of a poll. Sounds like that may have been
addressed. One good feature of Six Sigma is that it (finally)
encourages customer feedback. But, implementation of the program has a
caveat in that a customer is often assumed to be one that buys our
products. Care needs also to be taken to recognize that we have
"customers" that turn away and don't buy. Their feedback is needed for
the program to work. In fact, their feedback may be even more critical
than that of those who are long-term customers and have a forgiving
attitude. If this is to be successful, upper-management needs to push
to hear the bad news coming from those who turn away from us.
Steve
|
| 1225.28 | Escalation - why isn't the basement full of stairs? | TLE::AMARTIN | Alan H. Martin | Sat Oct 20 1990 08:08 | 20 |
| Re <<< Note 1225.22 by STAR::PARKE "I'm a surgeon, NOT Jack the Ripper" >>>:
You've outlined an organizational structure where problems can flow like this:
VMS Support/Maintainence Group
=>
CSSE VMS Support Group
=>
VMS Engineering
I have a question: if a CSC employee has a problem with VMS which they can't
solve by themselves, and which they cannot defer by entering an SPR (or QAR) or
a query in a product VAX Notes conference, which of the above 3 organizations is
their first line of defense - who are they supposed to contact first?
(I assume that the assertion "The [VMS] support[/Maintenance] group was ...
created to be the first line of RESPONSE to the customers" is inaccurate, in
that when a customer calls their normal CSC hot line number, they are not
connected directly to a support group member).
/AHM/THX
|
| 1225.30 | networking and layering... | BIGUN::ANDERSON | The Unbearable Lightness of Being | Mon Oct 22 1990 03:12 | 5 |
| I wonder if the folks that did the layered model for VMS etc have ever
looked at the new Digital Press book "5th Generation Management" by
Charles Savage? It may suggest some enhancements ... one good example
is the VMS Partners program : designed to cut through all that and get
the field, engineering and marketing together.
|
| 1225.31 | RE .28: | STAR::PARKE | I'm a surgeon, NOT Jack the Ripper | Mon Oct 22 1990 19:49 | 31 |
|
>You've outlined an organizational structure where problems can flow like this:
>
> VMS Support/Maintainence Group
> =>
> CSSE VMS Support Group
> =>
> VMS Engineering
CSC contacts CSSE:
Your flow SHOULD read:
CSC/GIA/SPR's etc
=>
CSSE VMS Support Group
=>
VMS Engineering Support/Maintainence Group
Which is VMS Engineering
There is no additional LINE of communication needed, it's
just that VMS/VSE's "project" is response to problems which
require engineering involvement.
This group has full access to the rest of the development
engineers and we can call on them if needed. We do not operate
in isolation from ZKO3-4 (or wherever) but we live in
conjunction with CSSE/VSG (physically).
To correct a possible misunderstanding of my response, we do not
replace the CSC, but, we do guarantee engineering availability
to CSSE and other groups.
|
| 1225.32 | Untanglement | TLE::AMARTIN | Alan H. Martin | Mon Oct 22 1990 22:25 | 11 |
| Re .31:
> Your flow SHOULD read:
...
> CSSE VMS Support Group
> =>
> VMS Engineering Support/Maintainence Group
Sorry, when you said "they can now walk 2-3 offices to get engineering support",
I misunderstood who "they" referred to.
/AHM
|
| 1225.33 | | SA1794::CHARBONND | but it was a _clean_ miss | Mon Oct 29 1990 13:37 | 10 |
| re .27 One small nit - Six Sigma includes one very important step-
identifying *your* customers. The people who buy DEC products are
everybody DECcie's customers, but anybody for whom you provide goods or
services is *your* customer. Your manager is a 'customer', your
employees are 'customers', the guy in the next department who
depends on you to do your job is your 'customer'. If all *your*
customers aren't satisfied, ultimately DEC's customers will get
unsatisfactory products.
A 'customer' is anybody who needs for you to do quality work.
|
| 1225.34 | Jon's memo getting some field visability | TODD::WARNOCK | Todd Warnock @CBO | Thu Nov 01 1990 00:37 | 10 |
| Jon's message (.0) is being circulated in the field, if nowhere else.
I received a copy from my Sales Support Unit Mgr, who got it from
District F/A, who got it from US Business Controls, who got it from
someone in Personnel.
The headers are "An Engineer's Advice to Jack Smith."
Interesting circulation !
Todd
|
| 1225.35 | Quality is free -- and profitable | WORDY::JONG | Steve Jong/T and N Writing Services | Thu Nov 22 1990 14:39 | 61 |
| This ongoing discussion of quality has been interesting. I highly
recommend Philip Crosby's book _Quality is Free_ to anyone seriously
interested in quality improvement. As the title of the book states,
Crosby argues that quality is not an extra expense or an extra effort,
but a way to improve products *without* cost. Quality, he says,
directly reduces the cost of sales and support, and thus increases
profits. That sounds good to me.
Having been exposed to the Crosby Quality Process at another company, I
have felt that the Digital approach to quality (quality is customer
satisfaction) has flaws. For one thing, it seems to foster an attitude
that quality is something you can paint on at the end. Quality, the
attitude says, starts at field test, when customers begin to react to
the product and you make adjustments to make them happy. As we know,
the longer you wait to fix problems, the more expensive it becomes, and
those expenses come at the cost of profits. It also means that some
"quality improvements" become too hard to do at such a late date, and
are deferred until a subsequent release.
I've done a little home improvement. I know that each layer of a wall
corrects the errors in the previous layer: the wallboard covers
mistakes in framing, the plaster covers mistakes in wallboarding, the
finish carpentry covers mistakes in plastering, and the paint covers
mistakes in finish carpentry. But it gets more and more difficult to
cover up mistakes as you go on, and the final result can be a wall that
looks good but begins to crack, a floor that squeaks, maybe even a
ceiling that falls down one day.
Another problem with quality as customer satisfaction is that a
customer who changes his mind can throw you for a loop. If you've been
developing a product for two years, and in the meantime a competitor
comes out with something that does things a little differently, you can
suddenly find yourself not satisfying customers. Now they want the
product in red. You scurry to make adjustments. Then another
competitor releases a product that's blue...
Crosby discusses "quality" at length, and domes up with a workable
definition: quality is conformance to requirements. Unlike idealistic
definitions of quality, this is something you can measure and make
work. In the customer-satisfaction model, a Jaguar is better than a
Hyundai, because customers generally (all but universally, I'd bet!)
are satisfied with the Jag and wistful about the Hyundai. Yet the
Hyundai could be perfectly made, defect-free, and utterly reliable,
while the Jag might be a lemon. Which is the quality car? By our
measurements, the Jag; by Crosby, the Hyundai -- because the Hyundai is
closer to the specs of the perfect Hyundai by being defect-free than
the Jag is to the specs of the perfect Jag by being a lemon.
Finally, after the product ships and the SPRs start coming in, what are
we doing? By the current thinking about quality, by fixing bugs we are
making the product better, adding quality. The more problems found and
fixed, the higher the quality, right? Of course, most customers
aren't reaping the benefits of these fixes; they're already stuck with
the copy they have. Field fixes are the most expensive of all to
implement. By the Crosby definition, a flood of SPRs only shows the
*lack* of quality of the product as it went out the door: the more
bugs, the lower the quality. That only makes sense.
Beware, then, of the declaration that "it's time to add on quality."
You're in for an expensive slip. While you're waiting around, get
Crosby's book.
|
| 1225.36 | | MU::PORTER | spam spam spam spam | Fri Nov 23 1990 00:34 | 6 |
| Absolutely. Quality is quite simple - it means designing and
implementing the bloody thing correctly to start with. It doesn't
seem to be a difficult concept to me at all.
(Now, it's a different question as to how we achieve that within
today's DEC)
|
| 1225.37 | | RICKS::SHERMAN | ECADSR::SHERMAN 225-5487, 223-3326 | Wed Nov 28 1990 16:19 | 12 |
| Customer demands are a moving target. There is always a lag between
what new thing the customer wants and what we can provide. If the lag
is too long the customer may walk and get what is wanted from a
competitor. The only solution that I can see for responding to this is
to foster greater creativity. Without this, quality programs and Six
Sigma will only help you to create products that your customers wanted
yesterday. If we don't do something more to emphasize innovation we'll
have to change our slogan to "Digital finally has it now."
Steve
|