Let me start this article with a quote from one of my favorite books I read many years ago:

"Quality, value, creates the subjects and objects in the world. The facts do not exist until value has created them. If your values are rigid, you can’t really learn new facts… If you’re plagued with value rigidity, you can fail to see the real answer even when it’s staring you right in the face because you can’t see the new answer’s importance."

Robert Pirsig

Zen and the Art of Motorcycle Maintenance

An Inquiry into Values

Quality in Business

Is it just me or do you find that quality in customer satisfaction is just not at the top of the list in many organizations today? Whenever I mention to a friend a problem I’ve had trying to fix a billing problem with an organization they always come up with a more serious problem they’ve had. Maybe that’s human nature and people just making conversation; maybe not.

Throughout my career I’ve been involved in developing and teaching how to build quality Information Systems and lately how the same concepts apply to human systems and management. The good news is there’s now an accepted movement towards quality conscious management where we recognize that we should approach "zero defect" systems using such things as continuous business improvement and bug-free software development.

As far as the Information Systems development profession is concerned it has finally evolved to a point where we can now build quality systems that have zero defects (i.e., no bugs) that do not deteriorate during production and modification (i.e. they can last as long as the business they support). That’s a good thing because Information Systems are becoming more complex. Lives are dependent on them in such areas as medical systems and air traffic control systems and commerce is very dependent on them. Bad systems can bring down an organization and put many people out of work.

Quality in Systems

The bad news is judging by the number of defects in systems and products there aren’t many systems development "professionals" around and the vast majority of systems in production today don’t even come close to zero defects. The phrase "computer system bug" is a recognized common phrase. Even my wife knows what a computer "bug" is, and she can’t read a line of computer code.

Many information systems suffer from hidden bugs that cause them to fail frequently and are so difficult to modify that even the people who built them expect them to blow up and have short production lives.

It’s not uncommon to have computer systems last as little as 2-3 years even though the business they support hasn’t changed (notice I say the business hasn’t changed - but the technology may well have). So many existing computer systems were not built for flexibility and maintainability. In fact, systems professionals at many companies are familiar with the monolithic, difficult-to-change computer system that "bites back" whenever they attempt to make a change to it.

Information Systems developers who are accustomed to this kind of system and don’t know a better way to develop systems, will generally tend to create new systems in the same style thus perpetuating the same undesirable system characteristics. I believe Information Systems developers should not make an organization be at the mercy of technology, allowing it to dictate the lifetime characteristics of business systems. I should also point out that manual systems that support a business tend to have an equal number of reasons for obsolescence and also suffer from unnecessary defects.

A Working Definition of Quality

Having been involved in teaching engineering disciplines for systems development for decades, I’ve often pondered what quality really is. It’s always seemed to me to be an ethereal concept, a feeling maybe.

For many years I felt that quality was "attention to detail." But that didn’t seem to ring true when I found myself in my personal life building something in my garage like a set of shelves and literally putting them together with some blocks and a couple of boards. I knew that even though I hadn’t paid too much attention to detail, I was quite satisfied with the resultant shelves. The result actually served my needs and I felt satisfied with the product.

One of the books I read that was fairly significant to me in this area of quality was "Zen and the Art of Motorcycle Maintenance" by Robert Pirsig (I started this article with a quote from that book). I found it interesting that in one of the chapters of the book, Pirsig thought that the divorce of art from engineering was an "archaeological wrong turn" and quite unnatural. That seemed to satisfy my inner feelings that there was some sort of "pride" that went into my work which had more affinity with art than it did with an engineering discipline. However, this feeling wasn’t an easy thing to teach in my seminars. It’s quite difficult to instill a "feeling of quality" into one’s student.

In my search for a definition of quality I was lucky to come across a book called "Quality Is Free" by Philip Crosby which summed up something that I could actually identify with, define and teach. That something was that quality is simply "conformance to requirements." If a product satisfies our requirements we believe it to be a quality product. This means it has the necessary level of quality we want - it’s that simple.

Quality as Conformance to Requirements

What I consider to be quality in a product or service is the consistent satisfaction of my requirements. The requirements and their satisfaction must both be measurable. Based on what I’ve just said, here’s my definition of Quality - building on Crosby’s definition.

Quality is recognized in a product or service when it satisfies both the ethical and measurable requirements of the requester. It is accomplished with pride of ownership on the part of everybody involved in satisfying those requirements.

This definition solved why I felt comfortable after having built a set of shelves that I knew hadn’t had too much attention to detail paid to them. The shelves satisfied what I was trying to accomplish and was something that would satisfy my requirements for a storage place. (Notice that I was the requester, not my wife - identifying the real customer is important.)

Identifying the Customer

Although I do still believe that there’s something to do with art as well as engineering that’s brought together to form pride in ones work, that just might have something to do with my acquired internal value systems. However, I hope we can all agree that quality is "conformance to requirements", especially when you look on requirements as having many different aspects.

What I mean by that is we can have requirements for the system to build a system or product. That’s my definition of a systems development methodology – a System to build Systems. So we should have requirements for the methodology we follow as well as requirements for the system or product that results from it. In other words, you can have quality built into the practices and the step-by-step procedures for building a house as well as for the resultant house that’s produced from using that methodology.

Obviously the requirements for a methodology change depending on the product being produced; for example, the methodology for building a skyscraper is different from one for building a log cabin. It follows that we can also have requirements for each activity or phase within a methodology; for the analysis, design, and implementation activities. So we have business requester requirements in analysis, system designer requirements in the solution, and implementer requirements for the implemented system/product. Having measureable requirements is at the heart of any profession.

By building in the necessary quality in each one of these activities, we can produce a system (human or computer) that has quality - at least the level of quality expected by a customer.

Now having said all that, maybe an organization that utilizes poor or "good-enough" systems simply expects and accepts that level of quality. I guess that’s fine if that’s a stated goal in their mission or charter.

Some History of the Quality Movement

There were a few pioneers that I’d like to mention in the evolution of attaining quality in processes and systems.

In 1930 a Professor Shewart working at Bell Laboratories identified that most of the problems resulting from a system were in the system itself and not in its implementation. He recognized that we could measure a process that produced some product or service by focusing on the process’ inputs and outputs. The areas of his study were the tasks and functions that took place in the office environment. One of his ideas was to use those measurements of the input into and the output from a process to eliminate the variations in the quality of a final product that came out of that process. This approach was called Process Control and its goal was to ensure an acceptable range of quality in some finished product.

Then, an individual by the name of Dr. W. Edwards Deming advocated the principles of quality control/management in production to put over the idea that we should eliminate after-the-fact inspections and improve the quality of the process itself. Deming introduced the concept of being aware of the customer as the person who ultimately had to be satisfied with the results of a process. He also recognized the quality added value to a product or service. His approach therefore extended the ideas of Process Control to include the customer who up to that point was an entity totally external to the organization that produced the product or service.

He questioned the value of after-the-fact inspections because he realized that the only thing you can do if an inspector finds a bad product is to throw the product away. Deming was a revolutionary when he said that we shouldn’t produce the bad product in the first place. Many people attribute Deming with the turnaround in product quality in Japan in the late 1940s and 1950s.

Dr. Deming and another person by the name of Dr. Joseph M. Juran looked at the principals of statistical control of quality and process built-in quality. They introduced some of the basic graphical models that we now almost take for granted as a means of representing processes.

Both Deming and Juran were given medals by the Emperor of Japan for their work. An award was created, called the Deming Prize, which is still sought today by companies looking to be associated with quality products and services.

In the 80s we saw the idea of "Quality Circles" as put forward by Professor Ishikawa. This idea centered on a process where teams would manage themselves and introduce continuous improvements in quality on their own (and not be managed by a hierarchical system). The idea here was that the best people to come up with quality suggestions were the people who were doing the work.

Of course there are many other approaches for obtaining quality such as Six Sigma which again looks at process improvement, and the International Organization for Standardization, ISO recommending standards for business and government worldwide.

In the United States the US government issues the Malcolm Baldrige Quality Award which recognizes performance excellence in both public and private organizations.

The Deming Prize and Baldrige Award (and others) are aimed at recognizing the introduction and ongoing improvement of quality in organizations.

Unfortunately, it’s rather difficult for a computer program to improve itself once it’s been written and installed in a system. A production computer system typically keeps the same level of quality for its life cycle as it had on day-one of its installation (or its quality could even deteriorate due to poor system maintenance and modification practices).

An implemented computer program has no feelings (not yet anyway). It doesn’t care about satisfying customer needs, but a human being that requested it and developed it should. The basic idea here is that as a human being in an organization, you should no longer look upon the procedure that is put in place today as cast in concrete. In fact, the focus of an organization should be on the question: "Do our systems efficiently satisfy our customer’s needs?" And, when one doesn’t, we need to constantly change that system and/or its individual processes.

From an implementation point of view this involves everyone. It involves the people who conduct the customer interaction, the people inside the system who may never see a customer (but who nevertheless are satisfying the customer’s needs), the information systems and the people who are the leaders and facilitators helping/facilitating the systems.

My own modest contributions to the evolution of ensuring quality in response to a customer’s need in an organization are the introduction of Business Event partitioning in the 1980s (which I now see reflected in the concepts of Event Stream Processing, Use Cases, Services, and Event Driven Architecture etc.). As well as the need to focus on six aspects of an organizations reaction to those customer Events: the Source, the Stimulus, the Processing, the Memory, the Response and the Recipient. I have also advocated for many years the creation of "seamless" business systems as a response to customer needs along these Business Event lines (e.g. ignoring traditional departmental or other organizational boundaries).

Quality is Free

The ironic thing about this discussion on quality is captured in the title of Philip Crosby’s book, "Quality Is Free." You see, actually producing a quality product ends up being cheaper than not producing a quality product. By the time you include customer satisfaction (i.e. not losing customers), the cost of discarding a poor product and all of the costs of installing inspections and testing mechanisms in systems, and, of course, the costs of fixing problems in development and "putting out fires" in production and recalls after a product is sold, then a non-quality product easily exceeds the cost of building quality into a product or system.

So I would even go further than Philip Crosby’s statement that "Quality is Free" and claim that quality saves you money in development and makes you money in customer satisfaction.

In my own profession I see way too many information system developers believe in testing errors out instead of not putting them in in the first place. Testing often just brings to light the presence of a poor development process. If an error is found when testing something it means there’s probably more errors to be found.

In my technical workshop seminars I would set up an exercise where teams would attempt to find errors in another team’s deliverable. I always liked it when a deliverable, after being reviewed by four other teams resulted in the comment "We can’t find anything wrong with this". There wasn’t a reward for finding errors there was a reward for the team that produced the error-free deliverable.

Now there’s a realistic phrase "You don’t know what you don’t know". I bring this up here because I’m not saying that we can eliminate all errors and defects in systems or products, however the errors that get through will be unknown errors, not ones that we can predict in advance. In other words the methodology should eliminate all known errors from making their way into a product. And of course the unknown error now becomes a known error that is used to improve the methodology.

So build quality into the methodology which will result in quality in the finished product.

I believe there’s a mind-set that goes with quality. You decide the level of quality you want for your organization’s systems and products - because your customers certainly will.