TQM PITFALLS - AND WHAT TO DO ABOUT THEM

by Jan Peleska and Cornelia Zahlten

INTRODUCTION

If you are currently planning a Total Quality Management (TQM) campaign in your company, you are in a much more fortunate situation than the TQM pioneers in the eighties: Today, the naive enthusiasm of the early TQM period has cooled off, it is well known that many expensive TQM projects have utterly failed, and - very fortunate for you - the reasons why goals have frequently not been reached have been carefully analyzed. The objective of this article is to illustrate some important "TQM pitfalls" we have encountered when doing consultancy and providing quality assurance services for several companies operating in the field of computerized control systems. For obvious reasons, we won't give you the company names, but it can be said that the problems described below are somewhat generic: it could happen to your TQM campaign starting tomorrow! Of course, we try not only to list the problems but also to give reasons for their occurrence and suggestions what to do about them. It should be noted however, that this analysis is based on our specific experience and you are welcome to discuss our point of view in a controversial way. In any case, thinking about and discussing potential reasons of failure will be beneficial for your company's TQM campaign.

PITFALL NUMBER 1: THE MIDDLE MANAGEMENT THREAT

This problem was personally experienced by the first author in about 1986 when working as a senior software designer with an international "global player". The company started its global TQM campaign in the appropriate top-down fashion, acknowledging that quality is a top-management responsibility: The CEO initiated the TQM campaign and proclaimed a well-defined mission statement about the goals to be achieved. The message was communicated in a series of TQM seminars for different groups with participants carefully selected according to their responsibilities and position in the management hierarchy. Coming back from his lower management seminar in a state of mind completely dedicated to quality - the seminar leaders had done a good job in motivating the TQM novices - a single experience was enough to shatter the author's freshly-gained trust into the benefits of TQM: During a confidential 10-minute conversation, the author's departmental boss made it explicit that "this TQM stuff" was a born-to-be-a-failure initiative of an old-fashioned top-management which actually should be replaced by more effective and energetic younger people. Obviously, the TQM seminar for middle management did not have the desired effect on the departmental boss, and the result of the conversation was surprisingly effective: Whenever a new step in the TQM campaign was announced, the author could not prevent himself from looking at this planned effort with the eyes of his boss. As a result, the TQM measures announced appeared to be insufficient and, even worse, in many cases ridiculous - the campaign had failed.

Summarizing, the pitfall can be described as follows: Whenever you start a TQM campaign, make sure that all influential people in the management hierarchy are on your side. In this aspect, middle management attitude has a special impact on the success of your initiative, since they communicate much closer and much more frequently with lower management than the top-level people.

There are two ways to encounter the threat described: If your company has a well-motivated and competent middle management, you should let them participate in the planning of your TQM campaign at an early stage. Their knowledge about problems and potential of the lower levels of your company hierarchy will help you to improve your TQM strategy. Their early participation will ensure that they will help you to transport the enthusiasm which is definitely needed for any successful TQM initiative to the rest of your company. The second way represents the unpleasant alternative: If top-management cannot rely on middle management to support their goals appropriately, it is time to think about lean management and re-organize your company hierarchy before venturing into a TQM campaign. Otherwise, the risk of wasting money on a useless TQM effort will be extremely high.

PITFALL NUMBER 2: THE RIDICULOUS QUALITY SLOGAN

Successful TQM requires a certain degree of enthusiasm, this is an accepted fact. Some companies decide to stimulate this enthusiasm with slogans expressing the TQM objectives in a simple phrase which is easy to remember and might be suitable to be used by "TQM cheer leaders" synchronizing the employees on a common goal. The use of slogans is controversial between TQM theoreticians, and we have seen them having disastrous effects on the motivation of people: Slogans usually oversimplify the quality goals; if reality is not as simple, the existence of the slogan will cause constant frustration because of its discrepancy with real-world experience in the company. It is not a good idea to announce a "zero-defects day" if your employees are working in a research laboratory where two out of three experiments fail because of their complexity: Where quality problems are due to the complexity of the development or production process, improvement can only arise from deeper insight into the nature of the process, so TQM measures should help to further this insight by providing better equipment, allowing more time for basic research or hiring experts in the field.

Summarizing, you can make use of slogans if the work is simple, but your employees are lacking motivation, and you should never use slogans if it is the other way round.

PITFALL NUMBER 3: THE CULTURE-REPLACES-TECHNOLOGY MISCONCEPTION

On another occasion we were giving a seminar about the ISO 9000 quality standards to a team working for an international consultancy company. When discussing some slightly complicated technical aspects about ISO 9000-conformant requirements definition and design specification for software-based systems, one member of the team said that he preferred the TQM approach to ISO 9000 because in TQM, all this technical stuff were no longer required.

This remark illustrates a widely spread misconception about TQM: It is true that TQM enhances the earlier quality approaches (inspection, quality control and quality assurance) by the "cultural aspect" and rightly points out that high and persistent quality requires an explicit commitment to continuous quality improvement by every member of the organization. However, this does not replace, but extend the older approaches. On the contrary, with respect to quality control TQM suggests even more sophisticated techniques to detect quality breaches than have been used before.

PITFALL NUMBER 4: THE QUALITY-MEANS-CORRECTNESS MISCONCEPTION

The final example is concerned with the different aspects of quality in a product. In 1998, we performed a very detailed test suite for a customer who had developed a highly reliable fault-tolerant computer system. To perform an in-depth test with high coverage, we used a test automation tool developed by our company which performs automated test generation, execution and evaluation based on specifications which can be interpreted by a computer controlling the whole test suite. In one aspect, the test suite turned out to be extremely successful: several deviations from the specified behaviour were observed in the fault-tolerant computer to be tested, some of the detected errors could only be uncovered by the the special method implemented in out test tool. However, the success was considerably diminished when it turned out that the end user who bought the fault-tolerant computer from our customer wanted to use the system in a way which differs from the behavioural specifications used in our tests. As a consequence, a good portion of the tests performed were superfluous since the end use will never put the corresponding functionality into operation. Other functional aspects that will be used stayed untested, because the specifications we used as input for the test definition did not mention these possibilities.

Summarizing, we encountered a typical discrepancy between the quality aspects 'correctness' and 'effectiveness'. The former means 'compliance with the specification', and this is what we checked thoroughly during the tests. The latter means 'suitability for the purpose of the end user', and this was unfortunately only partially covered by the specification available. Quality has several attributes (correctness and effectiveness being just two of them). For thorough quality control it is important to check compliance of the product with each of these quality aspects.

A LIST OF FURTHER PITFALLS

There is a number of other pitfalls which we will not discuss in detail; but in any case it is worth while mentioning them:

PITFALL NUMBER 5: THE PAPER PRODUCTION MACHINE. The ISO 9000 recommendations to document every important aspect of a production or business process may lead to tons of documented material which nobody will ever read.
PITFALL NUMBER 6: SPENDING ALL THE MONEY ON MINOR QUALITY IMPROVEMENTS. Sometimes most of the money and time invested into quality improvement gets spent on measures having only a minor impact on quality: For example, usage of better software development tools will typically improve quality by about 20%, while replacing an incompetent person by a competent specialists may improve the situation by a factor of 20!
PITFALL NUMBER 7: DON'T KNOW ABOUT QUALITY COSTS. If you don't track your costs used for quality assurance, it will be hard to argue why additional TQM measures might reduce quality costs in a long run. This is the most frequent reason why some quality campaigns are never launched due to financial reasons.
PITFALL NUMBER 8: MEASURING THE WRONG QUALITY INDICATORS: It is true that you should try to measure the quality of your processes and products. However, sometimes the urge to measure something leads to completely inadequate quality indicators: For example, software code inspections - if designed and performed by under-qualified people - often check conformance with naming conventions but fail to check semantic errors such as confusion between values and addresses, wrong implementation of specified algorithms etc. As a consequence, a piece of code with highest quality ratings may be completely buggy (but will certainly be nice to look at because the coding conventions have been observed in such a diligent way).
PITFALL NUMBER 9: TQM MEASURES ARE NOT APPROPRIATE FOR THE CULTURAL BACKGROUND. Before copying a set of successful TQM measures performed by another organization, it should be checked whether the cultural background of the organizations is similar: For example, setting up a system for anonymous quality improvement suggestions is helpful if the employees' cultural background does not encourage open criticism. In a company climate where problems can be openly discussed an anonymous system would be unnecessary.
PITFALL NUMBER 10: THE COMPETING-TEAM-PITFALL. Some companies allow different teams or departments to focus on similar things. This will almost certainly lead to competition and hostility between the teams, each accusing the other of being incompetent and using up all the precious money which could have been used for much better projects in the own team. If you start a TQM initiative in such a situation, every new TQM method appreciated by team 1 will be critcised as a waste of time and money by team 2 and vice versa. As a consequence, such a company has to launch two TQM campains - this is not a joke, it really happens: Two sets of development standards, two sets of development tools, two sets of check lists and so on.

CONCLUSION

Analyzing potential pitfalls when designing a TQM campaign is an advisable technique, comparable to the hazard analysis approach used in the development of safety-critical systems: You try to think about all possible "bad things" that might happen. Next, the causes that might lead to these hazards are analyzed. Finally, mechanisms avoiding these potential causes of hazards are devised. We recommend such an approach in the design of TQM initiatives, since a failure of such a campaign would certainly be hazardous for the future success of an organization.

ABOUT THE AUTHORS

Dr. Jan Peleska is professor for computer science at the University of Bremen. His research focuses on verification, validation and test of safety-critical computer systems. He is member of the Center for Computing Technology TZI, a research institute offering industrially-oriented research and technology transfer services in the fields of safety-critical systems, image processing, human factors in computing, intelligent systems, digital media and networks. e-mail: jp@tzi.org

Dr. Cornelia Zahlten is managing director of Verified Systems International GmbH in Bremen, a company providing test tools and quality assurance services for safety-critical and mission-critical computer based systems. e-mail: cmz@verified.de