Conference 7.286::digital

These are some thoughts from a member of the Internal Software Engineering
segment of Digital... 

These are my own thoughts and in no way are intended to represent any "offical"
viewpoint of the group I work in.


In addition to the thoughts I have put down here, I would like to add that 
things are already in a process of change, this group is part of the drive to
gain ISO9001 certification for UK Engineering.  The quality aspects required
by this certificate will (hopefully) be instrumental in achieving quality in
some of those working practices that have, in the past,  not been of the best.


                               ----oOo----
Communication Cycles in Internal Software production
----------------------------------------------------

What we have is this: 

+----------+   +-----------+   +-------------+   +----------+   +-----------+
| customer |..>| portfolio |<->| Engineering |<->| Analyst/ |<->| Engineers |
| reqs     |   +-----------+   | Mangement   |   | Designer |   | (product) |
+----------+                   +-------------+   +----------+   +-----------+
    ^   ^                                                             |
    |   |                                                             |
    |   +-------------------------------------------------------------+
    v
+---------+
| support |
+---------+


it tends to be a oneway street.  The Customer's original requirements are
interpreted at each stage of the process.  So the customer ends up with a
product that has a high risk of not meeting his requirements. 

It has even been known in the past, of releases of software where the Users of
that software have had no input into it's content...


What we need is this:

+----------+   +-----------+   +-------------+   +----------+   +-----------+
| customer |<->| portfolio |<->| Engineering |<->| Analyst/ |<->| Engineers |
| reqs     |   +-----------+   | Mangement   |   | Designer |   | (product) |
+----------+                   +-------------+   +----------+   +-----------+
   ^   ^ ^                             ^                  ^             |
   |   | |                             |                  |             |
   |   | +------------------------------------------------+             |
   |   +----------------------------------------------------------------+
   |                                   |
   +-------------------------------++--+
                                   ||
                                   v|
                              +---------+
                              | support |
                              +---------+

This is one of the few ways that a Customer will receive the product he wanted.
There is no way that a quality product can be produced by our Engineering
teams if the Customer is not consulted directly at the analysis and design
stages of the Project life cycle. 


We all know that what a customer says he wants is not what he really
wants/needs. Our job should be to talk his requirements over, providing him
with the chance to put our technical knowledge with his business and working
practice knowledge until the Customer is getting both what he wants and what
he needs in the most efficient manner.   This should not be the impossibility
that it seems to be today. Portfolio up to now has been a brick wall and none
shall pass... 

I have no intention of trying to be rude or dis-respectful, but as much 
experience as the members of the Portfolio groups have in their respective
businesses, they are not the ones who are going to have to *USE* what we 
produce, and quite often, Portfolio is made up of people whose technical 
knowledge dates back to the 1970's with little knowledge of how hardware and
layered products have advanced since then, and it these people who are
specifying technical updates to internal products, thus we in Engineering, are
constrained to out of date, inefficient, unsupported products to achieve their
requirements. 

There are antiquated business practices going on now in the field that make the
minimum use of the technology available to them.  They don't seem to realise
that by really using the technology, and allowing change to gradually be
introduced, instead of insisting on staying firmly entrenched in 1970's
technology (because they don't want to re-train their people) their businesses
could be assisted in being made more efficient and thus more profitable. 

There are groups out there today in the so-called telesales area that still
take orders over the telephone and write those orders on *PIECES OF PAPER* 
which are then sent to a "back room" to be entered onto the computer.  This is
in spite of the fact that there is nothing to prevent the telephone personnel
entering an order directly onto the computer.


There have been numerous complaints about the poor standard of code,
functionality and general quality of our internal products.  The Engineering
groups would dearly love to be allowed to improve this area.  They
unfortunately come up against the "cost" factor, so things remain the same and
the complaints continue.   Many of these poor standards have been inherited
from third-parties, very old software, etc...  even newer software has suffered
from poor change control practices in the past. Many of the problems have
stemmed from inadequate analysis in the first place (we come a full circle). 


I believe that Quality must extend to *ALL* areas of Digital.  We in the 
Engineering community can do our part, but I also believe that those barriers
between the "Field" (those who use our products) and "Engineering" (those who
Analyse and Design our products) must come down and direct two way
communication established.  I believe that Engineering must have a role in the
Pre-Concept phase of a project (when the decisions are made as to what goes
into a release of a project and is budgeted for at that stage) by the time
Engineering see Requirements, it is far too late for Engineering input to the
Requirements. 

I agree that the process of determining what can go into a release of software
must be the responsibility of Portfolio, and I agree that Engineering
Management must be responsible for contracting that work....but I also believe
that the Analysts and Designers who specify the end product cannot do a Quality
job by having access to those who will use the products they are specifying,
denied.  

If all of us could be a cohesive team, from the Customer, through Portfolio and
Engineering Management to the Engineering Analysts all working together on a
Project, instead of the process appearing to be a fight for "ownership" and
"power" that it appears to be presently, quality could be achieved at all
levels of Digital;  our Customers, those who *buy* our products, and ultimately
pay our salaries, can only gain confidence in Digital and our working practices
at all levels, the way we conduct our business reflects on our products.

The filtering process of having to go through 2 and sometimes 3 levels of 
management to get clarification to requirements is not the most efficient of
methods, especially when the questions asked, and the answers given (if any) 
are interpreted at each level.

We have efficient change control procedures in place, we are well aware that
authorization is required for changes to agreed requirements...what are we, as
a company, afraid of ?  people talking to eachother ?

    Small nit, but doesn't QFD stand for Quality Function Deployment?
    
    Mark.

    
    Re: .
    
    > Small nit, but doesn't QFD stand for Quality Function Deployment?
    
    It was introduced years back in the QFD class as meaning either 
    Quality Function Deployment or Quality Factors Development.  I doubt
    whether anyone knows if one or the other is the "correct" one.
    
    Steve
    

    An important thing to keep in mind about QFD is that the Q (Quality)
    does not mean quality in the sense of goodness (that is a quality car),
    but in the sense of attribute (this wine has a sharp quality).

    
    I think it's an interesting observation that a lot of people are
    getting excited about an acronym for which we have two distinct
    interpretations, both of which yield amusing variations depending on
    where you put the emphasis.
    
    If QFD is what I think it is, it should *at least* exhibit
    corporate-wide consistencey of meaning.
    

    	My interpreted definition of the term "QFD" as being that of
    "Quality Factors Development" originated from my Software Quality
    course at the Harvard Extension School a few years ago.  The course
    used the book entitled "Software Quality Engineering: A Total
    Technical and Management Approach" by Michael S. Deutsch and
    Ronald R. Willlis.  Edited by Randall W. Jensen (Prentice Hall
    publishers; ISBN 0-13-823204-0).

    	The book itself never actually uses the term "QFD", however
    it does define the various Quality Factors involved in the design
    and development of products which meet quality specifications.
    In fact, I suppose one good thing about this particular textbook
    is what appears to be a deliberate attempt to avoid the use of
    acronyms altogether.  In retrospect, I wish I had followed the
    same example in writing my original note.

    				   -davo

p.s.	So much for the "QFD" acronym...another Quality-related slogan
    	bites the dust of ambiguity.  ;^)

    
    Re: .5
    
    >I think it's an interesting observation that a lot of people are
    >getting excited about an acronym for which we have two distinct
    >interpretations, both of which yield amusing variations depending on
    >where you put the emphasis.
    >
    >If QFD is what I think it is, it should *at least* exhibit
    >corporate-wide consistencey of meaning.
    
    These are not "interpretations" and we *do* have consistency of
    meaning.  They are translations.  Quality Factors Development and
    Quality Function Deployment are just two different ways of expressing
    the same idea from the original Japanese.  If understand what QFD
    is about you can see how a translator could have arrived at either
    way of saying it.
    
    If your point is that perhaps we should agree to use one and retire
    the other that might be worth considering.
    
    Steve
    

    
    It goes beyond retiring one definition. I bet I can ask five managers
    within easy walking distance of my office what QFD entails, and get
    five radically different answers. To me, that is a strong indication of
    a "deployment" bug; once again, we are rallying to the acronym, and not
    to the spirit behind it.
    

    [Software] Quality Factors (reprinted w/o permission from Deutsch & Willis)
   ============================================================================
    1.	CORRECTNESS........Does the software comply with requirements?
    2.	EFFICIENCY.........How much resource is needed?
    3.	EXPANDABILITY......How easy is it to expand the software?
    4.	FLEXIBILITY........How easy is it to change it?
    5.	INTEGRITY..........How secure is it?
    6.	INTEROPERABILITY...Does it interface easily?
    7.	MAINTAINABILITY....How easy is it to repair?
    8.	MANAGEABILITY......Is it easily managed?
    9.	PORTABILITY........How easy is it to transport?
   10.	USABILITY..........How easy is it to use?
   11.	RELIABILITY........How often will it fail?
   12.	REUSABILITY........Is it reusable in other systems?
   13.	SAFETY.............Does it prevent hazards?
   14.	SURVIVABILITY......Can it survive during failure?
   15.	VERIFIABILITY......Is performance verification easy?

    
    Re: .8
    
    I agree we have a deployment bug, but that has to do with much
    more than just QFD.  We've had that problem for a long time.
    Probably the most notable example is the mess that was made
    of the Phase Review Process.  We allowed that to get out of hand,
    by not ensuring that everyone who needed to know about it, heard
    the same message.
    
    What I don't understand is your final point about rallying to the
    acronym and not the spirit of it.  Deployment is a logistical problem
    and could affect any methodology, no?
    
    Steve
    

    I believe that "Quality Function Deployment" is a closer translation
    from the original Japanese "Hin Shitsu Ki No Ten Kai". Certainly, the
    word "Deployment" is extremely important in this case; it implies that
    there is consideration of the entire lifecycle of a product, that there
    is a "deployment" of some kind, in both product development *and* its
    associated development, manufacturing and delivery *process*.
    
    "Quality Factors Development" is a term picked up by those who feel it
    necessary to promote QFD, ostensibly, as a Requirements Analysis
    approach, which is the way QFD is mainly used in Digital. However, the
    original intent of QFD is to deploy quality through a team of people
    who impact the product, in its every phase, so we've lost something
    important.
    
    Many people are attempting to implement Concurrent Engineering. CE has
    four major domains, as below. If a Product Team is doing well in these
    four areas, that team can be said to be doing Concurrent Engineering:
    
    	Planning (up-front planning and analysis of product lifecycle)
    	Teaming (people throughout the company working together)
    	SPPD (simultaneous product and process development)
    	Information Sharing (all information from the above easily access-
    			     ible by the team)
    
    If there is any one methodology that encompasses an integration all of
    the above four, it would be QFD, which also has the advantage of
    providing for the Voice of the Customer.
    
    But from this, it can easily be seen that we must stretch our use and
    understanding of QFD to become an integrated part of our approach, or
    even our product development process. It would then allow an
    implementation of ISO9001, for example. 
    
    Ray

    I think I should 'fess up:  I believe it was I who, having never been
    interested in QFD when I first heard it as "Quality Function
    Deployment" (assuming that it meant Deploy the Quality Functionaries)
    thought I would catch more fish if I baited with Quality Factor
    Development.  And Ray is right, I was limiting my sights merely to
    the House-of-Qualities,  the first matrix only.  In those days I was
    struggling to get a hearing for *any* use of QFD.  I'm delighted to
    know that some folks can see the limitations of our current one-matrix
    stopping point and are ambitious to go a lot farther.
    
    Here's an interesting sidelight on the translation question.  Jim Pope
    had me introduce QFD to some Japanese, from our Nihon Digital
    subsidiary.  (In those days I'm not sure Ray had tuned in;  and I
    certainly didn't know he speaks Japanese or I would have deferred
    to him for that visit, if he had been into QFD by then...)  Well, I
    asked Jim to have them bring a copy of Dr Akao's book from Japan.
    They did.  I asked them to translate its title.  Their response:
    "Quality Function Extension."
    
    Of course I then asked whether they could also translate it as
    Q F Deployment.  After a few moments conference in Japanese, they
    told me yes, yes, that would also be an appropriate translation.
    
    One other point to make about translation.  I don't remember how I
    heard this, but got convinced by someone that the meaning of
    "Quality Function" in Japanese includes everything the customer
    views as Quality.  In other words:  deploying the Quality Function
    has nothing much to do with Functionaries at all:  it's the
    totality of the entire Quality-appeal of a company and its products
    and service, as seen through the Customers' eyes.
    
    And one related point:  Dr Akao once spent a half hour explaining to
    a group of Americans (of which I was one) that the words "Quality
    Control" should not be thought of as meaning in Japanese exactly what
    they mean to our ears.  He said the meaning was between what we mean
    by "control" and what we mean by "management" and is actually closer
    to "management" as a Japanese hears it.  His intensity on this point
    impressed me.  I remember that Dr Shiba quoted Kaoru Ishikawa as saying
    "TQM is a Revolution in Management Thinking" and again, he seemed to
    be emphasizing this quite passionately.  These impressions from a
    couple of the leading Japanese gurus have influenced my thinking;
    when I point out that all of the TQM methods (except Taguchi's) are
    optical methods and call the whole bag of tricks "Managing By Eye"
    I'm attempting to name a little more precisely what this "Revolution
    in Management Thinking" comprises.  It appears to me to be a set of
    methods for managing in the presence of complexity.  I suspect that
    the historical reason that these methods come packaged with a
    Quality label could be that when the Quality Function (as defined
    above) is this broad, so that the whole enterprise must be delivered
    in the service of the customer's experience of Quality, there is going
    to be way more complexity to deal with than the older methods which
    I call Managing by Ear (language and numbers) allow us to cope with.
    
    								Russ

re: .12,

    	Well Russ, I'll admit that I did take one of your quality-related
    courses once years ago, so maybe you did plant the original QFD =
    "Quality Factor Development" bug in my ear.  But I'm almost certain
    that DEC is *not* the only English-speaking entity which has translated
    QFD in this way.  As I mentioned before, the entire Duetsch & Willis
    text which was used at Harvard is centered around the notion of
    "Quality Factors" and how these factors (also known as "fitness
    for use attributes") are translated from customer requirements,
    and which are themselves then matrixed against actual engineering
    quality criteria.

	I'm still not sure whether the textbook I mentioned actually
    uses the acronym "QFD" or not (I'll have to reread it some more to
    be sure).  As I mentioned, the textbook doesn't get too hung-up on
    acronyms (which is one reason I like it).  The subject of the text
    is actually referred to "Software Quality Engineering" which is that
    which spans the two traditionally distinct organizational realms of
    Software Engineering and Software Quality Assurance.

    	Anyway, the point of my basenote was to discuss ways of applying
    the sorts of software quality engineering methods which I assumed
    everyone was already agreed upon towards the development of an automated
    system to assist in the engineering of products at DEC (and perhaps
    elsewhere as well).  Since there are obviously different definitions
    of some of the most basic acronyms, etc., then it looks like I'll
    have to first backup and try to briefly explain the model before I
    can start proposing ways to automate it.  More later...

    				   -davo

p.s.	I guess my mistake in assuming a specific definition of "QFD"
    	is a little like assuming a Yourdon Methodology from the use
    	of the more general term "data-flow design" or "CASE".

    
    
    Re: Deployment vs. development
    
    Ray's explanation of the original meaning more properly translated as 
    "deployment" seems to make sense if you consider the Japanese idea
    of "hoshin" which means a coordinated, planned, "deployment" of focus,
    resources, and activities throughout an organization from the top down
    to ensure quality.
    
    Steve