[CLUE-Talk] Quality comments

[Grant Johnson]

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 
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.

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 
nearly impossible to change in a CMM environment, and cannot be deviated 
from, even if it is a better solution.

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.

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.

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.

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.

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.

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.



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.
>
>Kevin
>_______________________________________________
>CLUE-Talk mailing list
>CLUE-Talk at clue.denver.co.us
>http://clue.denver.co.us/mailman/listinfo/clue-talk