NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4884

Text File | 1992-12-11 | 7.2 KB | 141 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!ornl!utkcs2!darwin.sura.net!sgiblab!nec-gw!netkeeper!vivaldi!aslws01!aslws01!terry
From: [e-mail]
Subject: Re: Is SEI's CMM being used in Anger or just Marketing?
Message-ID: <[e-mail]>
Originator: terry@aslws01
Sender: [e-mail]
Nntp-Posting-Host: aslws01
Organization: NEC America, Inc Irving TX
References: <[e-mail]+ <[e-mail]> <[e-mail]>
Date: Fri, 11 Dec 1992 18:38:21 GMT
Lines: 127

Hi folks,

Note to Dan Drake:  Yes, I believe that was your posting.  Thanks for the
posting and subsequent nice feedback.


PHILIP CROSBY AND THE CMM  (HEY, IS HE GETTING HIS ROYALTIES FROM SEI??)

Regarding the posting that Philip Crosby of ITT was the originator of the
concept of a 5-level quality maturity (CMM) model in "Quality is Free":

*Very* interesting, and more than a little bit surprising to me.  I've had a
lot of interactions with SEI in the past, and while this piece of information
may or may not been buried away somewhere in all that pile (I haven't checked
yet), I honestly don't recall ever noticing it.  Also, I have no recollection
at all of Philip Crosby every being mentioned I attended SPA training for a
week at SEI. (Tim Kasse was our primary teacher; he is a superb instructor
on process issues and improvement.  Watts Humphrey gave a pep talk, too.)

In contrast, Deming's name was used like popcorn both in the discussions of
quality and (especially) in Watts Humphrey's book.  Thus it's easy to see
why folks have gotten the impression that the CMM is directly derived from
the Demings work; the two keep getting mentioned in the same contexts.

Actually, I'm also a bit annoyed.  For having authored such a key concept
in the SEI process effort, Philip Crosby and his work should have been
discussed and announced a LOT more loudly.  I don't think I'm alone in having
incorrectly assumed the 5-level model to have been entirely Watts Humphrey's
personal work (which, until that posting, was exactly what I had been
assuming).

It does appear that SEI is now doing a better job on this -- I checked a
recent item by them and was pleased to see Philip Crosby and his book
mentioned right up front.  (And again, I may have just missed it before
in the older materials, so it could well be my fault for not seeing it
before, not theirs.)

Needless to say, I'm going to be buying Philip Crosby's book as quickly as I
can locate a copy of it.  I am *definitely* looking forward to reading it,
because I want to know what the original concept developer thought about it.


*EARLY* PROCESS IMPROVEMENT (WHETHER CONTINUOUS OR NOT)

In article <[e-mail]>
[e-mail] (Bonus, Iniquus, Celer - Delegitus Duo) writes:

> In article <[e-mail]>, [e-mail] (Dan Drake) writes:
>
> | The reference may be to a recent message of mine contrasting my
> | perceptions of Deming's and SEI's outlooks.  Having read Out of the
> | Crisis doesn't make me any kind of expert on Deming, much less Juran,
> | but consider this: Deming's consistent message is that hundreds of
> | companies have got into Continuous Improvement, outside of Japan as well
> | as inside, and he loads his writing with success stories.  *Obviously*
> | he doesn't think that a super-elite Level 5 status that virtually nobody
> | has achieved is a prerequisite.
>
> Dan's point is fundamentally correct.  The ISO certification process requires
> continuous improvement from the get-go.

We had an internal software engineering conference recently.  I presented a
paper on something we call "Cooperative Process Improvement," or CPI, which
is a "friendly" approach approach to process improvement developed that I've
been working on here.  In keeping with some earlier highly successful internal
process improvement work some of us did under Clem McGowan back at Contel,
CPI places a very strong emphasis on respect for personnel, application-
specific expertise, and the fact that people within the project often have
a far better idea of where the big bottlenecks are than any outsider can
have.  You listen, you listen again, and then you listen some more; and
lo, when it comes time to change the process, they listen back to you with
respect and interest!  It's a doggone effective technique for identifying
and making changes that help your process work better NOW, instead of five
years down the line.

At the conference we gave our report and were able to point out some quite
nice short-term improvements we had achieved in areas of overall software
methodology, configuration management, documentation, and general morale.
It did not cost us much to do (I think it was a total of about three
man-months at that point in time), but because it emphasized reuse and
"pulling together" previously disorganized resources in a readily understood
fashion, the impact was significant (and important to an external customer).
This made for a nice paper, since we could point out good cost-effectiveness.

Another component had a paper on how they were following the general outline
of the CMM model and were hoping that in a couple more years they would be
able to show some kind of payoff in terms of quality impacts and their
ability to produce software in a timely fashion.  After the talk the author
expressed frustration with the slowness and cost of the effort -- they had
had three people on it full time for over a year, and still could not show
anything that demonstrably impacted their cost effectiveness.

The point?  While the CMM does, as George rightly points out, give a lot
of good ideas about what how to get good management and software engineering
practices into place (the "rules of the road" again, if you will), I have
a *lot* of problems with the way it tries to order things.  Our experience
in bottom-line results both hear and at Contel is that the FIRST thing you
should look for are the process problems with the biggest payoffs.  Waiting
until you have umpteen different "metric programs" in place before you
begin to apply good old-fashioned common sense to whatever is going on
NOW is just a recipe for disaster -- plus you run a very real risk of
actually "fossilizing" highly detrimental process features by decorating
them with all sorts of data collection and management techniques.  In short,
you should get the really ugly limbs sawed off your Christmas tree *before*
you start sticking all sorts of expensive goodies on it.

> The CMM is not gospel, but it can be useful.

I concur, but with the qualifications above that organizations should not
put off until later what they can easily improve on now.


ISO 9000

Incidentally, for whatever it is worth I will be looking in detail into
the ISO 9000 effort soon, which heretofore I've only taken a very cursory
glance at.  (Wish me luck!)  It should be interesting.

                Cheers,
                Terry Bollinger

+--------------------------------------------+-------------------------------+
| Terry Bollinger                            | Phone: [phone]           |
| Advanced Switching Laboratory, NEC America |   Fax: [phone]           |
| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: [e-mail]   |
+--------------------------------------------+-------------------------------+