Logical Conclusions Inc.
What is Quality in the Business world?
AKA "You can’t add a pound of quality to a process."
By Brian Dickinson, President Logical Conclusions, Inc.
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.”
"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 and costly. 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 crash and have short production lives.
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.
The house building profession analogy I used above is quite common however it is close to home (no pun intended) for me because I’ve actually built my own homes. On my first house I did the majority of the work myself - carpentry, plumbing, electrical, and so on (I even developed muscles). On my second house I contracted out some tasks and took on the role of project manager.
Having built many systems and then having built two houses, I clearly saw the parallels between the two activities.
Now, let me ask you some questions relating to the concept of building in quality:
Have you ever seen a house being built? - Maybe near where you live or on your way to work.
A new house typically seems to go up very quickly; You may see the land being cleared, then the foundation concrete being poured, then the framing, the roof, the windows installed etc. What we don’t see are all of the planning, up-front analysis, and design work that went on before any of the construction.
Let me ask some more questions:
When the house was completed, have you ever see the construction crew push against a wall to see if it would fall over?
Or, have you see them aim huge fans on the house to see if it would withstand strong winds?
Or, have you passed by when they get the fire department to spray the roof to see if it leaked?
You haven’t? Neither have I!
We just don’t expect the builder to “test” a new house after it’s built to compensate for poor building techniques. Problems which show up after the house is completed show the poor construction methods and materials used during development and/or the lack of quality in the design. This should be true for systems in an organization.
I’m not saying: “Don’t test systems”, rather that after-the-fact testing is not a quality assurance activity and it should not be used as a substitute for thorough business analysis and system design. My house building experiences have taught me that “quality” has to be built-in and demonstrated at all stages of development.
For example in house building, land recording/surveying, ground surveys, architectural drawings, blueprints, structural calculations, heat loss calculations, and so on, all have to be externally approved prior to any construction. Moreover, local government staff (building inspectors) also inspects every stage of the construction itself. Any aspect of the construction failing to meet the national and local building code standards must be brought up to code by law before construction can continue. And, of course, as each stage is completed, the cost of making an after-the-fact change (such as modifying the plumbing or raising a ceiling) goes up dramatically.
Obviously, the house building is analogous to systems development in an organization. We need to make sure that the developers of a system have a good set of goals, and a Project Charter for any project that they undertake, as well as the skills and tools needed to do their job. The design of the actual human and computer systems should be created with the idea of satisfying the organization’s business people and customers.
The house building analogy I use may break down in places when compared with human and computer system. However, in general it works very well because house building and System Engineering share the following characteristics:
• Specific start and end points
• Significant deliverables
• A strong client/developer relationship
• Periodic, intermediate quality assurance checkpoints
• Risk (financial, project, and finished product)
• Dramatic escalating cost-of-change as the project proceeds
Moreover, both house building and systems development:
• Involve many people
• Require complex coordination of many different professional skills
• Require specialized building tools, including “power tools”
• Use models for conceptualization, communication, and overcoming complexity
• Use off-the-shelf, modular, and reusable components wherever possible.
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 principles 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 are 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.
I hope you liked this short article. If you have comments I can be reached at:
Contact Logical Conclusions Inc.:
Link to our other video website:
Logical Conclusions Inc.