Total Engineering Quality Management

Ronald J. Cottman, Cottmon

• Publisher: CRC Press
• Year: 2020
• Print ISBN: 9780824787400
• eBook ISBN: 9781000148077
• Topic: Business
• Subtopic: Project Management
• Index: Business

This manual discusses how the Total Quality Management (TQM) of the production and manufacturing environment can be modified, implemented, and measured within the engineering project environment. It aims to integrate predominant quality philosophy with organization research.

1
Managing Toward Improvement

Total Quality Management (TQM) as practiced in the United States is still in its infancy. Management of engineers and engineering organizations, on the other hand, is a practiced art with a solid foundation built over many years. Total Engineering Quality Management (TEQM) is a combination of the two. The tendency, therefore, is to pursue establishing a TQM plan just to be among the front-runners in a new field, and to ignore the key idea that before the Q in TQM can be brought about, the M must be brought solidly into the game. In other words, the basic foundation of management principles must be studied and implemented in any engineering environment before success in TEQM can be logically expected. It is virtually impossible to place too much emphasis on the study of the persons whom the engineering manager is going to manage. Without an understanding of the engineer and the engineering personality, the Total Quality program is doomed to failure.

An engineer needs to feel free to pursue his own ideas to a point of completion. Problems can result if an engineer is made to feel he is being closely supervised. Rules and regulations other than the laws of physics are a burden to the engineer that he would just as soon not be bothered with. Although he recognizes the existence of regulations, there is a tendency among engineers to bend those rules as far as possible without experiencing an actual breach.

To effectively manage engineers and engineering processes, a manager must place himself in the same logical surroundings as an engineer. In some cases the engineering manager has functioned in an engineering atmosphere for years. He is aware that an engineer’s training requires him to be unwilling to accept rules unless some logical reason can be seen for doing so. It stands to reason, then, that to effectively control an engineering process, the manager must understand the engineers who are a vital part of that process.

The Engineer Today

The engineers of today look somewhat like the following: they resent administration; they have a strong desire for freedom in work; they are preoccupied with detail, technically oriented, well educated, and perfectionists; and they are logical, take pride in their work, and have a great respect for competence. They expect that people will be as predictable as physical laws. How then do we manage processes that exist in the same environment as this complex personality?

Statistical Process Control For The Engineer

The engineering atmosphere is well suited as an area in which to apply process control. Statistical Process Control (SPC) is accepted by engineers as part of the mathematical discipline to which they are accustomed.

Although a difference may exist in responsibilities and specific goals, every engineering process manager will need to perform the identical basic functions if he is to be effective. The process or processes that will lead to completion of a project on schedule and within budget must be selected. The long- and short-range goals of these processes must be carefully explained in detail to the engineering personnel.

The engineering manager who wishes to motivate engineers to use SPC must make that use a part of the engineering process. In a case in which dealing with SPC becomes an additional task, the engineer will tend to resent it.

Engineering Manager has SPC Success

Minnie the Manager and the engineers whom she supervised had been working together for more than five years. She was respected by each of them as an engineer who had come up through the ranks and who knew her stuff. Last week, Minnie was instructed by the VP of Engineering to implement a program of SPC into the lab test flow. The failures of a ramp generator card being integrated into a new system were to be charted, tracked, and traced, and the source of the errors corrected. Minnie knew she had a problem. To insist that her guys stop in the middle of a test to chart the faults of a failed device was more than she could bring herself to do. Not only that, but she didn’t believe that she would have done it when she was working in the lab. What to do? Minnie left the VP’s office shaking her head . . . and then it came to her. Project Engineering was already using SPC to track budget anomalies. The test engineers were already logging card faults into their engineering notebooks. Minnie the Manager had only to convince Useful Ulysses, the cognizant project engineer, that Racing Rhonda, the project analyst who worked for Useful and was tending to project SPC budget charts, could spend a few more moments at the end of each day charting the faults listed in engineering notebooks.

Minnie walked down to the water fountain where she knew Useful Ulysses the project engineer spent much of his time. She smiled gently and presented her problem. Useful Ulysses was, of course, delighted to offer assistance, and Minnie was “home free.” Racing Rhonda was overwhelmed with joy at having an opportunity to be of assistance by adding this small task to her work schedule, thus proving beyond all doubt that . . . TEAMWORK WORKS.

In the above scenario, Minnie sets a good example of handling SPC implementation. When process control through the use of statistical charts must be initiated, not only must these processes remain flexible, but the manner of implementation must be compatible with those involved.

Comparison With Other Communities

Engineering project managers, in establishing controls to bring the various processes of their project to a successful conclusion, must also be aware of the processes in related departments with which they must interface. A comparison of the engineering manager and a line manager in some other environment points out fundamental differences. The line manager’s task consists mainly of directing the activity of those employees whom they manager. They expend a great deal of time evaluating personnel and the circumstances surrounding the use of personnel. In comparison, the engineering manager should pursue his managerial responsibilities in a somewhat different manner. The highly individualized engineers within the engineering manager’s section may resent direct advice from the manager. Were evaluation of an engineering process required, then the engineer would expect to personally evaluate the process. While the manager may well be a fine administrator, failure can be expected if the sensitivity of the engineering personality is ignored.

Psychological Considerations

Understanding the emotional complexity of the technical mind can be of great assistance to the engineering manager. Having worked in the engineering environment for years, the manager already understands those who are working for him. However, an understanding of general managerial psychology can be helpful as well. The following insight was brought about when Douglas McGregor, in his excellent book The Human Side of Enterprise,¹ examined the assumptions normally made about people at work in various organizational systems. He felt that the basic assumptions of owners and managers greatly affected the way they went about their management tasks as well as the way organizational structures were built and run. On one side he placed the following assumptions associated with the personality he classed as the Theory X person:

• The average individual dislikes work and tends to avoid it if he can.
• Most individuals have to be pushed, directed, controlled, and threatened with dire consequences in order to get them to do enough to carry on with the work of the organization.

On the other side, McGregor labeled these assumptions as associated with the Theory Y person:

• People do physical or mental work as easily as they play or rest.
• People will show self-discipline and direction when they are committed to the objectives of an activity.
• Commitment to objectives is related to the rewards associated with their achievement.
• The average person in a proper setting not only learns to accept responsibility but also seeks it out.
• The capacity to contribute imaginatively and creatively to solving the problems of an organization is widely distributed among people.

Understanding the McGregor study will enhance the engineering manager’s overall capacity to deal with even the most complex personality and thereby provide a more satisfactory scenario for employee interaction.

Engineering Manager Splits Adams

Adamant Adam was a fine example of McGregor’s Theory Y. Not only was work as natural to him as play, he easily accepted responsibility and displayed creativity. Adamant Adam was a dandy worker who did one-and-a half days of work every day. Adamant worked in the same software lab as a co-worker who shared a portion of his given name. His co-worker was a big, strapping guy named Indolent Adam.

Indolent Adam was a shining example of the Theory X personality. Not only did he avoid work, but it was said of him that he was “born lazy.” Responsibility was to be avoided like the plague and he had to be threatened in order to restrict his coffee breaks to less than an hour. He performed only enough work to keep his job. However, Indolent was one sharp programmer when he felt like working.

Mickey Einstein, the new software manager, was becoming painfully aware that the work produced by this team was being written by one person. There were just no differences in style. He called Adamant Adam in and asked pointed questions about the manner in which work was being accomplished, and Adamant gave all the right answers. Mickey called Indolent Adam in and asked the same questions. There were very few answers forthcoming. Mickey knew he had a problem. He had to motivate Indolent Adam. Mickey started his campaign in a time-tested manner. He called in the employee who worked closest with Indolent to get some feedback on anything Adamant Adam may have noticed in conversation with Indolent which might indicate apparent problems. And Adamant unloaded.

“Darn right,” Adamant said, “he feels that he is underpaid and you aren’t interested in what he does.” Mickey was shocked. Were his managerial skills slipping? “Not only that,” said Adamant with feeling, “all of us in the lab feel like we’re in a closed box. The lab is badly lit, rarely cleaned up, and the chairs are uncomfortable.” Mickey stood, thanked Adamant for his feedback, and Adamant went back to work. “OK,” said Mickey to no one in particular, “I can fix that stuff. Certainly Indolent is worth the consideration. But I don’t think those things encompass the whole problem.” Then the light went on in his mind. Use the motivational factors he had studied in school.

Mickey the software manager began going into the lab each afternoon to go over the work produced by his team of two. Indolent was somewhat uncomfortable at first, but as Mickey praised the team for their efforts it was just as apparent that the praise was enjoyed equally by both members of his team. He went one step further into his good management processes and began to assign specific, trackable tasks to Indolent. Further, he increased the employees’ authority to make changes on their own and was pleas...

Table of contents

• Cover
• Half Title
• Series Page
• Dedication
• Title Page
• Copyright Page
• About the Series
• Preface
• Table of Contents
• Introduction
• 1. Managing Toward Improvement
• 2. Processes and Systems
• 3. The Process as a System
• 4. The Engineering Process Team Concept
• 5. The Engineering Process Team Approach
• 6. Development of the Problem Solution
• 7. Statistical Control of Processes
• 8. Process Control Charts
• Epilog
• References
• Index