| Trends Newsletter - Implementing Quality Programs |
|
It is common knowledge among banking managers that we need to constantly improve the quality of our products and services. The recurring question is "How do we do it?"
Recently, at one large, well-managed bank, the Trust Operations managers attempted to answer the question and jointly concluded that they should implement a comprehensive Quality Program to improve their timeliness and accuracy. They looked at their firm and decided that since it had a strong history of hierarchical decision making, and since their people were not trained to develop their own programs, the best approach would be to design the Mission Statement and the overall philosophy of a program, explain the goals to the supervisors and staff, and then let the supervisors implement the new Quality Program.
To begin, the managers invited a cross-section of supervisors and staff to a kick-off session. In the words of one of the managers who attended the meeting, "The supervisors' reaction was disastrous!"
RESISTANCE TO CHANGE
It is not unusual to encounter resistance to Quality Programs since these programs usually change a firm's culture, and cultural changes need a structured process with special emphasis on communication. During their own "after-action" analysis, the operations managers realized that they had given very mixed signals to the staff. They knew that the message they wanted to give to their supervisors was:
We, your managers, have identified a new way to improve the quality of our processes. The direction of the new program is easy to follow, and will help you do an even better job. All you have to do is embrace the concept and begin.
They realized that the supervisors heard a very different message:
We, your managers, have concluded that you are not doing your job as well as you should be doing and we have defined a program that will rectify your deficiencies and for which you must now become responsible.
This message may not have been received as the managers intended since people basically react to change along two dimensions: their typical reaction to any change, and their reaction to this specific change.
People who have negative reactions to change tend to do so for several reasons, including:
- Fear of the unknown, or inadequate information
- Fear of being unable or slow to learn new skills
- Threats to their expertise or power
- Threats to their pay and perquisites
Any significant change, whether it is perceived as a positive change or negative, can cause some combination of stress, uncertainly, disruption and insecurity that is different in each person. A classic research study at MIT discovered that the physiological response to change is the same for changes that people see as good as it is for those they see as bad or threatening.
People react to change differently, based upon a variety of factors: their ability to assimilate information, life experiences, aptitude, attitude, motivations, age, position, etc. And, they react differently as a result of the behavior patterns they have developed over the years. These patterns of behavior were formed to help them simplify their daily decisions and activities. Successful use of these patterns in a daily routine reinforces the patterns and makes the person more resistant to change. Any threat to the patterns is perceived as a threat to their success.
IMPLEMENTING CHANGE
Implementing change successfully in today's environment requires specific training and experience and does not come naturally to most managers. Since most change today involves some transformation of behavior as well as process, the techniques used to institute a change must be very people-oriented. In the past, a process change involved defining the project from the top down, and implementing it from the top down. More frequently today, the change can be defined from the top or the bottom, and the change has to be instituted from the top and from the bottom. As our staff become partners in the process (albeit junior partners) they must be allowed to provide input if they are expected to take ownership and exercise initiative.
Overcoming resistance while implementing change requires leadership (which involves helping others reorient their thinking), and a Project Management process (which provides a framework for executing decisions). Many different methodologies for Quality Programs exist. They all have similar steps but differ in the points they emphasize. Some are totally quantitative, some are highly structured, and some define themselves in customer terms. At The Summit Group, our approach to quality is defined within our Total Process Management methodology. We emphasize the human factors, and seek to generate enthusiasm through Ownership, Leadership, Teamwork, and Empowerment. Everyday, individual managers experience this need to balance a structured approach with good people management skills, as is shown by the personal experiences of three managers that are included as case studies in this article.
CASE I - WHAT IS THE GOAL OF A QUALITY PROGRAM?
"While implementing a Quality Program as the manager of a Securities Operations area in a large money center bank, my managers and I overcame some resistance to change. Initially, we confused the definition of an ultimate standard with the definition of our goals, and therefore misunderstood the value of our accomplishments. We were only able to improve our process by first improving our communication with our staff. Within my first few months as a new Department Head, the timeliness and accuracy of Trust Statement Rendition had risen from 87% to 95%. This was a significant accomplishment and had involved an outstanding effort by all of my managers and their people. I had defined several projects: source/cause analysis, process decomposition, line item analysis, overtime reduction, etc.; and they implemented the projects in an exceptional manner. When I asked my managers to strive now for 98%, they resisted. "We've worked our %$## 's off for months to get the results up to 95%, and now you want more. You'll never be satisfied!" After a lot of thought, I realized that while I had always been aiming at 100%, I had not convinced everyone that 100% should be the ultimate target, and that by constantly increasing my managers' goals I would only frustrate them since some fundamental systems deficiencies would almost certainly prevent us from reaching 100% in the foreseeable future. In an open discussion, we all realized that we had confused the definition of a standard with that of a goal. After a lot more discussion, we all agreed that while the only acceptable standard in a process such as ours was 100%, we should establish achievable interim goals. Every client who signed up for our service deserved our commitment to error free, on-time processing and we needed to work towards this aggressively, and realistically. This gave us the opportunity to have many small successes as we moved, step by step, towards the standard." Successful Quality Programs require a managed process of standards, goals and planning. JOB COMPETENCIES There are many different categories of work, and different competencies are needed to be effective in each category. When you change a process, very often you change the required mix of competencies.
Job competencies consist of: Attitudes, Motivations, Aptitudes, Knowledge and Skills. If you have a job where Attitude and Motivation are less important then you can use a management style that only requires obedience and conformance to the defined process. However, if you have a job that depends upon an individual's Attitude and Motivation, and most jobs today do, you must use a different management approach.
Case ll - IS A TOP DOWN COMMITMENT ENOUGH?
"My senior manager peers and I were told by our boss that since he was now obsessed by quality, we must become similarly obsessed, and that we had six months to implement the complete Quality Program that he had selected. Several of my peers saluted smartly and installed a very slick program that involved lots of charts and reports, and claimed victory. These managers constantly identified new areas of opportunity, prioritized them, and assigned people to specific tasks. They improved their process -- but only in the areas that they could recognize as requiring attention. And, they spent much of their time administering the program and re-prioritizing the opportunities to best utilize the limited available resources. They had established an excellent Process Improvement Program, but it was not a Quality Program. Some of us saw it a little differently. We said that while we would certainly put in a Quality Program, we couldn't commit to a timetable until we understood the problem and how to obtain our staffs' commitment to the solution. Our boss was not happy initially, but he did support us and he let us design our own approach. We felt that the Program that he had selected had a good methodology -- but it wasn't ours. And, if we were truly going to become obsessed about quality, it couldn't just be something that we were told to do and that we would impose upon our subordinates. We talked about quality a lot. We asked our supervisors what they thought, and we asked our staff. Every chance we got we talked about how other firms had implemented quality programs and obtained outstanding results. We started to improve our own personal actions, and we were constantly looking for specific examples of good quality/service that we could discuss in our staff meetings. After about four months of talking, one of my junior programming managers walked into my office. She said that she and her team had listened to what I had said about quality and they were tired of just talking about quality and waiting for me to do something. They had decided to use the offered methodology to begin their own program. They decided that they would check each other's code. They said that their goal was to avoid moving any code into the Test Region that would have errors that would be discovered by their users during Acceptance Testing. They only had a few graphs and reports, and their graphs could have been slicker, but no one could have designed a better quality program for them." Successful Quality Programs require Commitment, Communication and Coordination QUALITY PROGRAM METHODOLOGIES The search for the perfect Quality Program has become another Quest for the Grail. Some firms have become so intent on implementing a program that they have decided to become ISO 9000 compliant and compete for the Baldridge Award. What they often fail to realize is that the selection of a methodology and a Program Manager is only the beginning of a significant culture change. Most Quality consultants stress that in order to be effective, the Quality Program must be a firm-wide effort. At The Summit Group, we think that since a quality program can be of immense value to a firm, the broader the acceptance, the greater the benefits. However, in the real world we cannot always wait for a firm-wide commitment. Managers at all levels have the opportunity to establish a quality ethic in their own area, and then they can try to influence other areas by demonstrating the value of the program. Successful implementation of a Quality Program, or any program that involves a change in a job that depends upon employees' enthusiasm, is best accomplished with an approach such as the following:
Case lll - WHAT'S THIS THING CALLED EMPOWERMENT, AND WHO CARES ANY WAY?
"As one part of an extensive employee communications program, I held periodic lunches with groups of junior officers and managers, and periodic breakfasts with different groups of non-exempt staff. These meetings were designed to move information directly to the staff and to get direct feed back, without any interpretation by middle mangers. Most of the non-exempt staff in my systems organization worked in the Data Center, and there were always some problems that we could discuss. As the people became more comfortable with the informal format, the number of problems they identified rose. I added a "scribe" to make sure we didn't miss anything since the discussions were often quite involved. When anyone pointed out a problem in one of these meetings, my Chief of Staff assigned someone to look into it immediately. The assigned manager was tasked with preparing a written evaluation and response that would be sent to me and to the person who brought up the problem. The more problems we resolved, the more that were identified. Just running this program was starting to become a full time job, until one day, when inspiration struck. A Report Distribution Clerk from the Data Center had a problem that he surfaced at one of our breakfasts. Among other tasks, he was responsible for initiating, running and delivering a report three times a day to a certain operations unit. Over the last few months, the operations unit had begun to request the report more and more frequently. Each time that he ran the report, he had to hand deliver it. While he was doing this he wasn't available to take other requests, so some of his users were beginning to complain. Either something had to change, or he needed help. There were several obvious solutions: we could add staff (not likely); we could tell the operations unit that they were only going to get the report as scheduled, and if they wanted a change they could request it through the proper channels (good luck); we could install a local printer (a good data center solution); we could put the report on line and let the user request it as needed (the development people would be happy with that); etc. But why did the unit need the report so often? Had something changed in the process? Was there a particular problem or opportunity? My first inclination was to have one of my managers talk to the supervisor for that unit. My inspiration was to have the Report Distribution clerk do it. I explained to him that he should record the number of times that he had produced the report over the last few weeks on a graph, put a line on the graph to represent the existing standard from our published Service Level Agreements, and then have a meeting with the supervisor to explain the situation and determine what should be done. The clerk protested. He said that he had never made a graph outside school and that he couldn't just call up an AVP and ask for a meeting. We used the rest of the breakfast to talk about graphs and how they are used to help visualize a situation, and then I told the clerk that he had my authority to call the meeting. He looked skeptical, but he agreed to do it. I didn't expect to hear from him again on this topic. I was wrong. About a month later, the clerk called my secretary to schedule a meeting with me. With Me! When he arrived, he had his graph, and showed me how he had recorded the activity each day. He explained that after the first meeting with the operations supervisor, the requests dropped to three per day since the report really wasn't needed more often than that, but he kept recording the volume. After a week the volume started to rise again, and he talked to the supervisor again. The requests then dropped to three per day and had stayed there for weeks. The problem was solved. He was proud. I was overwhelmed. I realized that I had stumbled onto something. There were 300 people in my Division. Even if I solved one little problem like this every day of the year, I still couldn't get as much done as when each person in my division solved one problem per year. And, what if they were sufficiently trained, empowered and energized to solve one problem per month, or one per week? I realized that's really what managing people is all about!" Successful programs are implemented through people who have the right tools, training, etc. .
SUMMARY In summary, there are many different methodologies that can be employed to implement a Quality Program, and a reliable system with well-defined procedures and policies are essential; however, the most important aspects involve people. When we understand the competencies required in the jobs, use a proven methodology, and support all of our activities with Ownership, Leadership, Teamwork and Empowerment, we can generate all of the enthusiasm a Quality Program requires.
|