[CLUE-Talk] Quality comments

[Kevin Cullis]

Grant,

You're absolutely correct in some of your cases below.  See commments
for each below.

Grant Johnson wrote:
> 
> He is right.  99% of the time, the "quality" initiatives I have seen spend
> so much on administration of the effort, that they are
> counter-productive.  I was in a CMM level 3 organization.  In order to
> achieve this level, a full 1/4 of the staff did nothing but administer the
> program, and the other 3/4 were micro-managed into hating their lives and

Yes, even I hate it when someone finds my mistakes, and depending on how
they approach me, I'll either hit them with the nerf arrows for pointing
out my missing something and learn from it (because they know that I
don't come to work absolutely motivated to screw things up), or I'll be
"passive aggressive" and "slow work down" because they came from a
"workers are out to screw up" mentality.  I'm normally teachable (i.e.
listening to Linux gurus for learning new ways of doing things), but I
won't be teachable when I'm confronted with "Hey you lard, your screwed
this up!!"

> accomplishing nothing.  As a result, morale was bad.  Unhappy people make
> poor products.  Well, at least we were more consistent, now instead of a
> small amount of the stuff being over budget, behind schedule, and a poor
> quality product the user never wanted to begin with, then all of it was.

You can only go as fast as the weakest worker no matter how hard you
try, that's the bottleneck of ANY organization.  Either that person is
allowed to increase his/her skills/etc (some don't, most will), or you
find someone who can, but the true issue is to make sure they understand
that THEY have to improve themselves to improve the organization.

> 
> Here is my start at a philosophy that produces REAL quality, without the
> micromanagement that every CMM and ISO9000 initiative I have ever seen.  It
> has to do with the approach, and not every little detail.  Most
> importantly, it allows for CHANGE.  Not following the "standard" can be
> good.  Sometimes the "standard" becomes outdated.  At that point, it is

But you've missed the point, EVERY methodology follows a process and
you've just pointed out that the "standard" was improved, but why wasn't
it put into the process?  Just because it's an "improvement," doesn't
mean that it will work ALL the time, but if there isn't a chance to try
the improvement, then I would guess that fear/ignorance/skepticism/etc
is keeping the improvement from being adopted, much like Linux in
corporate IT department.

> nearly impossible to change in a CMM environment, and cannot be deviated
> from, even if it is a better solution.

The reason for the "impossibility" for change is to ensure that ALL of
the parties involved understand the change and how it may affect them.
The key issue is when you change one aspect, how does it change the
system.  You and I both know that we've made changes lots of times where
it has caused more problems which causes fear to stop ANY changes. Most
people don't want to find out WHY something happens.

> 
> 1)  Start at the high-level view of the project.
> This must be defined before anything else can begin.  Any changes to these
> requirements should be viewed as enhancements or additional projects, and
> part of the original scope.

I totally agree.

> 
> 2)  Modular designs.
> If designed from the beginning as being modular, additional features as
> well as fixes to existing features will be much simpler.  New features are
> simply new modules, and problems can be easily isolated.

Again, totally agree!!

> 
> 3)  Open systems.
> All communication between modules should be done in the simplest way
> possible.  Simplicity enhances maintainability, performance, and
> integration.  Secret methods of communication and deviation from standards
> only create a system that is not maintainable because the troubleshooting
> is close to impossible.

Agree!!!

> 
> 4)  Use the right too for the job.
> Do not use a product for development simply because it is a "corporate
> standard."  Use the tool that fits the job.  You may have to go to bat for
> your tool, just be ready to support your decision.

Awesomely agree here!!!

> 
> 5)  Bugs are NOT acceptable.
> A piece of software with "a few quirks" is not done.  No software should
> ever be released without being able to say "no known issues."  If a feature
> is not perfect, either finish it, or remove it from the release.  If it is
> important enough to be needed in the release, it is important enough to be
> bug-free.  If you cannot find your bug, swallow your pride and get help.

Couldn't have said it better.

> 
> 6)  Do not announce schedules prematurely.
> Announcing a release date before the feature set is even defined is
> suicide.  On anything but the smallest of projects, even announcing during
> alpha testing is equally stupid.

Yes, time to market does NOT bring about a quality product. See the book
"Built to Last" and you'll see what I mean.

> 
> At 10:26 AM 01/02/2001 -0700, you wrote:
> >  > Do You Buy Into Management Methodologies In IT?
> > > http://slashdot.org/article.pl?sid=00/12/30/1936250&mode=thread
> > >
> > > Saw this and it reminded me of all the conversations that have been
> > > going on about this subject.
> >
> >What do the CLUE people think of this?  How right is he?
> >
> >For those that are interested, I hope to be interviewing OMI, the recent
> >Malcolm Baldrige award winner here in Greenwood Village, in the next
> >couple of months with the hope that I can interview their IT department
> >director to see how they do it. I've asked the question, just waiting to
> >see if it'll be OK.

Grant,

You've laid out some good points and principles to work by (when you
writin' the book ;-) ). I recently worked for an organization which
believed in the monkey process: "push this button, hit this key" way of
"training" people and I was sick of it.  Once I understood the process,
I was able to make it simple to understand (because I brought in the
"higher level" aspect of it) and it improved the new hires retention,
but did "management" understand it?  No, they just scoffed at it even
though each and every person was up to speed that much quicker, but
because I didn't "document" it, it did not get into my "performance"
file because documentation was perceived as "a waste of time."  While I
agree, Grant, that there can be OVER documentation, having NO
documentation is worse, and my morale after such an incident wasn't
happy about it, but moved on anyway.  For those of you who want better
performance reviews and bigger paychecks, would you like to not have
your good work go unnoticed like mine above?  Documentation is to point
out the good AND the bad and to respond to each appropriately, too bad
most of the time the documentation of bad results are used as a hammer
rather than an opportunity for improvement.

Kevin