This is the first of a series of articles about simple things you can do to improve the quality of information services delivered to your end users. Quality is for many of us a mysterious and elusive goal. We generally know it when we see it, but asked to define it we are at a loss to describe it. At least it's always the other guys problem - MIS departments would be sooo much easier to run if the hardware, operating system, or ?? vendor had better quality products!
"Quality" has recently become a full-fledged member of the buzzword club and gained international prominence when the entire European Economic Community supported a quality standard from the International Standards Organization generally labeled ISO 9000. This year, the enforcement of the standard will start restricting imports into the EEC from companies that don't meet these quality standards. While this article is not really about ISO 9000, the ISO standard will be important to you for two reasons. At the pragmatic level, if your company does business in Europe (or is an identifiable subcontractor for someone who does) you will have to quickly address these standards to stay competitive and/or to stay in the market at all. From the more immediate point of view, the standards are a good way to begin to understand and come to gripes with the thorny issue of quality control in MIS. They are tough reading, but contain the essence of quality management in ANY environment.
For decades, large companies have been working on various kinds of manufacturing quality programs using statistical process control. They have done this because they have discovered a simple truth -- it's cheaper in the long run to build-in quality from the start rather than having to repair the defects later in the manufacturing process or in the field. Statistical process control is normally used to ensure that the next widget off the assembly line is just like the design widget. It is conceptually easy to measure and correct the deviations from standard when you are monitoring a repetitive manufacturing process such as building ten thousand computers or duplicating ten thousand copies of software. It is harder to apply this particular type of quality standards in software departments where each project is different. How do you create standards or statistics when each project is unique and non-standard? The answer is contained in the ISO 9000 concepts and is simple when you understand it. You must back up a step and create a non-physical process model to measure deviation from. In other words, you begin to measure and address quality issues in the design and management process itself. Instead of measuring the widget directly, you measure and control the quality of the design process for widgets. As such, ISO 9000 is not a product standard but a process standard.
Companies have always had a responsibility for the design quality of their products and the current legislative environment has drastically accelerated the economic effects of this responsibility. The cost of the repair goes up by orders of magnitude with delays in finding and fixing the defects. Some recent high-profile manufacturing examples include the wiring harness problems with the Saturn automobile and the Hubbell telescope. In Saturn's case, not only was the cost of a ten cent design change blown into several hundred dollars per car, but a well deserved reputation for quality products was damaged. I bet they can't even estimate how many millions of dollars this one error will cost them in sales and customer loyalty over the next five or ten years.
What is the total cost of a billing program that under (or over!) bills customers? Or an inventory system that incorrectly maintains inventory balances leaving you short of critical inventory or long on obsolete stock? The damages range from lost and dissatisfied customers, to unrecoverable dollar losses, to possible civil and criminal actions. "Can't happen here" you say? I personally know of a company that introduced an application bug into their system which caused them to double bill a large number of customer credit card accounts. This perfectly innocent bug was piggy-backed into the system during a very hurried fix of an unrelated problem and was not discovered for over two weeks. By then the problem had become critical -- they had damaged their reputation with some of their most valued customers, several State Attorney Generals were calling the bug a case of consumer fraud, and the credit card clearing company was afraid to clear legitimate credit card charges leaving them in a cash flow bind. This company eventually went out of business, at least partially because of a simple, uncaught application software error.
Where do you start when dealing with quality? Well, many of the now familiar advertising slogans contain serious grains of truth -- "Quality is job one" comes to mind, and with all due respect to James Earl Jones, "We don't make QUALITY, we earn it" has a ring of truth also -- quality doesn't just happen, it takes hard work to develop quality! Next months column will focus on some of the more easily implemented mechanics of improving quality in business applications. This month, I think it's important to first concentrate on the environmental requirements to earn a reputation for quality. In a relatively intangible service business like data processing, quality is a goal and attitude as much as it is a procedure. It can all too easily be discouraged by unintended management messages.
For starters, quality (or the lack of quality), like many corporate traits, comes straight from the top. Every company, no matter what its product or service, has a set of corporate goals. The successful ones publish their goals in a formal organizational goals statement and/or policy manual so all the employees can work together toward the stated goals. If you want to have quality as a corporate goal, you need to say so loud and clearly up front. Without this kind of reinforced, public recognition of quality as a formal goal, it is too easy to let other issues such as deadlines, cost considerations, or just plain laziness push quality out of the hearts and minds of your employees. By the way, the first way to fail an ISO 9000 quality audit is to fail to have "a formal statement of the management quality policy widely known to the staff at all levels". I caution you however, developing a clear set of quality goals is no easy task.
The second issue is to budget for quality. There is a well known book by one of the original authors in the quality field, Philip Crosby, called "Quality Is Free". Its a catchy title, but a little misleading. A better statement might be "Quality may not be free, but it's a whole lot cheaper than the alternatives." By this I mean while quality efforts certainly take resources, this 'investment' will return a profit downstream. You absolutely need to invest regular energy to develop measures of quality, and to devise and implement quality improvement programs. For very small companies this might mean dedicating a quarter or even half time from an individual already on board to quality issues. For most companies it represents several people dedicated to software testing and various forms of quality assurance programs. Another point here -- if quality is a corporate goal, it should involve everybody. It is important to regularly ask for everyone's input and suggestions on how to improve your processes and your products.
Thirdly, having given them the needed resources, challenge your people to do better. After you have developed meaningful quality measurements, prominently publish the results and reward significant improvements somehow. If individual effort can be measured, base a part of employee bonuses on quality. Throw a party for the team if overall results improve. Remember the squeaky wheel concept -- people tend to work on the visible issues. At Sequoia, we focused on the mean time between system outages caused by our Pick implementation as an overall measure of software quality and were able to improve it by a hundred fold to over 230,000 hours. If you want to improve quality, make it visible and it will improve. Guaranteed.
Stay tuned next month for a series of low cost, common sense ways to begin implementing a gradual improvement program aimed at developing consistent quality benefits for your application design and programming groups.