This is the second article in a series about improving the quality of the information services you deliver to your end users. Last months article outlined a few reasons why you should look into MIS quality issues. Implementing a quality program for MIS departments encompasses a lot of ground. Quality shows up in or impacts virtually every phase of your operations, from customer requirements reviews and application design documents, to programming design, coding and testing, and into the installation and support cycle.

With so much to cover, its no wonder most managers simply ignore many indications of poor quality. However, the cost of ignoring quality problems is more and bigger problems, as issues snowball. On the other hand, because most medium sized MIS departments are in a precarious state of balance, a massive effort to change procedures has a significant potential to disrupt the parts of the system that are working, potentially causing a real crisis. I think its generally safer and more productive to make a series of small, low risk changes. This allows time for you and the organization to absorb and adapt to the changes in a more controlled fashion.

How do you begin to instill quality into your programming efforts? The simple approach starts by asking where in your programming task does a lack of quality show itself? A little informal data collection will most likely tell you where your operation has problems. Don't get too sophisticated -- no computer data bases required at this stage -- just document on a sheet of paper or 3x5 cards where the complaints are and the most obvious cause of the complaints. Take time to gather a volume of data, analyze it, and develop a feeling for where the major problems lie. Remember the whole world operates on a version of the 80/20 rule. Eighty percent of your problems are caused by twenty percent of the system and if you can direct your energy to the right spots, you can often get spectacular results for a very small investment in "steering" energy.

Lets say you find simple changes to parts of the system taking way too long to accomplish or introducing an inordinate number of bugs. This is a really common quality issue and the likely reasons are poorly understood code or undocumented interfaces which have to be researched each time this area is touched. The obvious solution is to properly document the area, but the trick is in how you chose to accomplish the documentation. Most managers want to take charge and get a quick fix, but in so doing make several long lasting mistakes. They decide to assign someone to "go in there and document the whole mess", and then usually find they "can't afford" to assign the best programmer so they use the most junior person on the staff.

Now, human beings in general and programmers in particular have become really good at reading between the lines. No matter what you say, if you put junior people on it, you send the message "this (documentation) is unimportant" to the rest of the staff. How is the junior guy supposed to know the code and what is important to document? With no easy way, they end up wading through the code and documenting everything -- the obvious and the obscure, the important and the trivial -- all in one big lump. Often, the documentation is wrong because they believe the easily outdated code comments. You have also exposed the untrained documentor to the worst code around, potentially teaching them to reproduce such poor code. Finally, the project is frequently truncated or aborted part way through when the harried manager begins to believe this dubious value project will last forever. Sound familiar?

Is there a better way? Perhaps. You need to develop a trigger which will cause you to document only the most important material, and do it correctly. One easy to implement approach I've found, is to make it a part of everyone's responsibility to determine when a simple change or bug fix takes "too long". If your shop is already well structured, you could trigger this rule if the actual time to change/fix exceeds the estimated by some percentage, otherwise, just let the programmers make the determination. Assuming the problem can be improved with documentation, the person who did the change should be made responsible to write a short document (usually one or two pages) outlining the tricky code, poor interface, hidden gotcha, or whatever caused the problem. Include in this the responsibility to fix any incorrect code comments and leave the section of code 'just a little better' than they found it. This low energy code cleanup fights the natural code decay process and extends the useful life of your systems.

The obvious benefits of this approach are you have the best people for the job doing the documentation when they are up to speed and familiar with the code and you will only document problem areas. Put these short system notes in a central file accessible to everyone. Then use them to train the junior people or to refresh the best when they have to re-open this particular code swamp. Better still, you could use them to tell you where your system needs redesign or recoding. Within a year, I guarantee you will have accumulated a substantial volume of relevant, low cost documentation and have far fewer critical problems.

Let's look at another area. Who hasn't had trouble delivering on schedule, controlling bugs, or motivating people? Everyone has, and while there is certainly no single magic solution, there is an easily implemented aid I can share with you. It is almost to simple to believe. Its human nature for everyone to want to be part of the team. If you make your problems, goals and performance visible to everyone and allow everyone to have input, they will work smarter and likely harder for you. You know the kind of things I'm talking about -- the "Community Thermometer" effect bringing people together into a team effort.

In most organizations, an unbelievable amount of energy is lost because many people don't understand the corporate goals or don't get the word in time when goals change. By keeping the goals in front of the staff it helps people stay focused and work on the corporate goals rather than personal sub-goals. The format is not as important as the visibility. One quick caution here, people work to optimize what gets measured, so display only material measurements. Don't measure output in lines of code a day in the absence of quality and functionality or you'll get a lot of useless lines of code a day. The other important part of this secret is to really work hard to ensure the openness and teamwork of the process. If all the programmers know the schedule is impossible, but are afraid to discuss it and offer suggestions, you have shut out your best source of validation, feed-back and schedule optimization.

Achieving quality results is not as hard as it seems, but as I said earlier you can't legislate it, you have to earn it. If you demand your people complete a man year project in a quarter, you are not displaying a desire for a quality system. If you ask them to produce a system from poor or incomplete or wrong specifications, you are asking for a poor, incomplete and wrong system. Its your choice, but be careful -- you tend to get what you are really asking for, regardless of what words you use!

In future columns I hope to share some additional but often overlooked ways to take better advantage of the innate desire of your employees to do the best job possible. In closing I would like to reiterate the fact that quality needs to be a top down corporate attitude. Management is responsible to put quality on the MIS agenda and to fund it and support the changes it will require or it will wither away. In order to make real progress at improving your own situation, you will need to foster, from the top down, the attitude that "good enough to get by" simply isn't.