We have had a very positive experience working with Organized Change. They designed a survey for one of our global teams to help design an organizational change and develop scenarios for our strategies. Organized Change is a dependable collaborator who can be relied upon to help us meet our goals.
David Chaudron, PhD
The Wall St. Journal has twice reported on the struggling efforts of companies trying to improve overall quality and customer satisfaction. With such hoopla, why are so many faltering?
Based on our experience, there are several significant causes to an organization's TQM efforts stumbling or stagnating. You can use this information to avoid these pitfalls, or recover from them if you have "fallen in."
Some organizations treat process action teams (sometimes called quality improvement teams) like candy: They want dessert before having dinner.
I know of a 3000-person organization with over 70 current process action teams (PATs) working on a variety of issues. The organization avoids measuring their success, provides them little technical support, and still has not addressed the systemic changes needed to support them. This implementation strategy has a high risk of failure, and TQM will probably not become an integral part of their culture.
This problem occurs when, paradoxically enough, an organization achieves successes with its first teams, or hears about wild successes of other companies. They then buy a canned training program, or hire a consultant to setup their TQM efforts. Much training occurs and many PATs formed. With various degrees of management support, these PATs attack a variety of problems. Unfortunately, because of unclear long-term plans, and the lack of system changes, (see next section) many of these PATs fail. As a result, the quality effort may stagnate, and once ardent supporters become disillusioned.
Management must realize that to fully implement TQM, satisfy its customers, and promote teamwork in the entire organization, often wrenching systemic changes must be made: Profit sharing may be introduced; individual performance appraisals may be radically changed or eliminated; organizational structure may be realigned away from functions (production, quality, engineering) to a customer-, process- or geographic-based structure; information may be given to employees formerly reserved for senior management; and significantly more authority may be given to line employees.
If management does not align these systems, the effect will be like Dr. Dolittle's "Pushme-Pullyou" animal (a horse with two heads, each pulling in the opposite direction). Each system (rewards, structure, information, etc.) is tugging the organization in different directions. The result will be much struggle and confusion, but little success.
Many organizations need to design the architecture of their quality effort. If they do not, they risk pouring time and dollars into an effort that will eventually collapse. Among the decisions that should be made up- front, before implementing a quality effort are: the measures of success; the degree of employee involvement; the depth and breadth of implementation; and the techniques to be used. As someone once said, "If you don't know where you are going, you may not like getting there."
I have often seen SPC (control) charts in company offices like so much wallpaper. Someone, I'm sure, has a job updating these, but they otherwise serve no purpose. Organizations create them because they believe they need to, but do so without knowing why. An organization's need may revolve around identifying their customer's needs, so that Quality Function Deployment (QFD) is more appropriate than control charts. Well- designed experiments can significantly reduce the need to monitor every aspect of product quality. Team building among top executives can often solve the problems that mass training of supervisors in meeting management cannot.
Many organizations buy "canned" implementation efforts that describe for them, step by step, what to do. This "square peg" approach is often not appropriate for the "round hole" of the organization. This kind of effort can often lead to the overuse of PAT's and the problems with mass training (see next section).
On the other hand, organizations can become infected with the "not invented here" (NIH) disease. They insist in reinventing the wheel when it isn't necessary to do so.
The secret to TQM implementation is not to choose between one and the other, but to decide what aspects of implementation can be bought, and what aspects need unique solutions agreed upon by management and employees.
If you wish employees to use their training, organizations must train them in skills specific to their needs just in time to use them. Too many organizations have spent untold thousands of dollars and hours on training employees on concepts they may never need. If they do need these concepts, they will need refresher courses because their training was long ago. Because mass training puts such a burden on organizational resources, not all members of work teams are trained at once. As a result, some know what to do but others do not, which causes more confusion.
Supervisors and line employees have often complained that they do not receive "management support" for their efforts. I believe all parties are at fault for this problem. Management may not fully realize what they specifically need to do to support PATs, and PATs choose to 1) work on problems that don't interest management or 2) don't get the proper authority and specific support from management before they start their efforts. This "no management support" is caused by unclear or unknown expectations.
An interesting problem in TQM is hero worship. There are Deming worshipers, Crosby worshipers and Juran worshipers. These cults of personality often get in the way because any concept not uttered by one's hero is suspect and probably not true. Organizations can often get into this "labelitis" by swallowing any wholesale labeled TQM, and avoiding any concept not labeled as such. One example of this happened earlier this month: A client said he wasn't interested in becoming a team-based organization because "it wasn't TQM.